16 ms·
DenoDB
- croes 5y agoToo bad that MS SQL is not included.
- libria 5y agoAgree, wish MS ecosystem had more support. Looks like it was given some thought though: https://github.com/eveningkid/denodb/blob/bb319c03085612c108773c654fda47c18f32117e/lib/translators/sql-translator.ts#L9-L16 https://github.com/eveningkid/denodb/blob/bb319c03085612c108...
- burlesona 5y agoIs it just me or is it weird to see an ORM that wraps over 4 relational databases and… Mongo…
- pininja 5y agoDefining the schema in application ORM with Mongo seems helpful. While the DB doesn’t enforce a schema, I always want to have one.
- dhritzkiv 5y agoIt is weird. TypeORM does this too, and based on its documentation, there's a lot of caveats. Judging just on that, I imagine there's a lot of compromises that have to be made.
- FlashBlaze 5y agoI really recommend to check out his channel: https://www.youtube.com/c/eveningkid https://www.youtube.com/c/eveningkid One of the lower subscribed well produced tech channels I've seen in a while.
- abraxas 5y agoIs this referencing some unexplained relation to the post or just vlog spam?
- JacobLinney 5y agoThe channel name is the same as the github username of the deno db author, so I think it is actually related despite the content not seeming to be Edit: And the authors website links to this channel
- Santosh83 5y agoSame person. Their GitHub profile is linked from the above Deno repo, and their website is linked from their GitHub page, and that in turn links the Youtube channel, in addition to the obvious common user name.
- sergiomattei 5y agoHoly shit, this is actually a killer app in Deno. Great work developers!
- flakiness 5y agoLooking at the dependencies, I realized that it is now common to implement database bindings purely in the host language (vs. using vendor provided C/C++ SDK.) Deno PG [1] and MySQL [2] does it. This makes sense considering Deno's security model. But Node libs do the same [3][4]! This also kinda make sense, as node-based JS has to be async most of the time. Still it's such a hassle. Anyways, kudos to both communities. You've done a lot! - [1] https://deno.land/x/postgres@v0.11.2 https://deno.land/x/postgres@v0.11.2 - [2] https://deno.land/x/mysql@v2.9.0 https://deno.land/x/mysql@v2.9.0 - [3] https://github.com/brianc/node-postgres/tree/master/packages/pg https://github.com/brianc/node-postgres/tree/master/packages... - [4] https://github.com/mysqljs/mysql https://github.com/mysqljs/mysql
- eloff 5y agoIt's because synchronous libraries that block don't play well with async event loop code like node or deno. You'd have to run them on a thread pool and pass data back and forth to avoid blocking. This phenomenon also happens in go and rust for similar reasons.
- wrnr 5y agoWriting extensions in rust is also an option, not done it myself but it seems to use the systems shared library capabilities: https://blog.logrocket.com/how-to-create-a-deno-plugin-in-rust/ https://blog.logrocket.com/how-to-create-a-deno-plugin-in-ru...
- pjmlp 5y agoIt was already common with Java and .NET, hence why the vocabulary types define multiple levels for the database drivers. For example with JDBC: Type 1 driver - JDBC-ODBC bridge Type 2 driver - Native-API driver Type 3 driver - Network-Protocol driver (Middleware driver) Type 4 driver - Database-Protocol driver (Pure Java driver) or thin driver. Most modern drivers are all type 4.
- flakiness 5y agoMost of Java drivers are different since there is official implementation. That's possible mainly because Java is very popular language. Deno is more community driven. Maybe Node is closer to Java these days.
- Osiris 5y agoI hate ORMs with the fury of a thousand suns. The problem is that I know SQL but now I have to spend a bunch of time trying to figure out how to convert SQL into ORM X just so it can convert it back to inefficient SQL. SQL mostly translates between various databases but ORMs are unique and you have to learn a new API for each one. I'm on a project using TypeORM and it has been fantastic at helping developers on my team make really bad schemas due to not understanding how to use TypeORM to make the right relationships. Currently I'm looking at pg-types because you just write SQL and it just helps by making some TypeScript types for you. (I have used ORMs in C#, PHP, and JavaScript and I hate all of them).
- hn_throwaway_99 5y agoYou're being downvoted, but I completely agree. If you are on Node and Postgres I highly recommend using slonik - it makes it easy to just write SQL but at the same time makes it almost impossible to have mistakes like SQL injections: https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf410349856c https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41... https://github.com/gajus/slonik https://github.com/gajus/slonik
- bhj 5y agoAlong similar lines but more simple/agnostic, check out node-sql-template-strings[0] or sqlate[1]. [0]: https://github.com/felixfbecker/node-sql-template-strings https://github.com/felixfbecker/node-sql-template-strings [1]: https://github.com/moll/js-sqlate https://github.com/moll/js-sqlate
- mirekrusin 5y agofor mssql https://github.com/appliedblockchain/tsql/ https://github.com/appliedblockchain/tsql/
- girvo 5y ago> it makes it easy to just write SQL but at the same time makes it almost impossible to have mistakes like SQL injections While I think this is totally the way to go, it is kind of amusing that PHP's PDO system was the "right" way to go all along in some ways
- atarian 5y agoThe link and title made it seem like something official from the Deno developers but it's just a mirror for https://github.com/eveningkid/denodb https://github.com/eveningkid/denodb
- nichch 5y agohttps://deno.land/x/ https://deno.land/x/ is explicitly for third party modules.
- dang 5y agoOK, we'll change to that from https://deno.land/x/denodb@v1.0.38 https://deno.land/x/denodb@v1.0.38. Thanks.
- bartlomieju 5y agohttps://deno.land/x/ https://deno.land/x/ is a service from Deno, but it's a registry for 3rd party modules. There's no need to change the URL
- dang 5y agoThe HN guidelines ask "Please submit the original source. If a post reports on something found on another site, submit the latter," and I assume the github link is closer to being the original source. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- breatheoften 5y agoAt first glance -- async/await mitigates a lot of my least favorite things about orm dsl's -- namely that it can be difficult to tell when the orm framework is actually going to generate a db round trip without being familiar with the implementation ... thinking back to the most recent orm i had to learn (rails) and how it was quite annoying to get started with while interacting with an existing codebase. clear suspension marking would have made the code vastly easier to follow and allow making inferences about where things were happening even as a unfamiliar with the dsl ...
- mcintyre1994 5y agoThis doesn’t always work with Node APIs, one example that comes to mind is fetch (for making URL requests). When you await a fetch(url) you get a response object, where a bunch of functions on it (like json() IIRC) are themselves promises - but not making another API call. I’m not actually sure why it’s structured like that, I guess to give unified error handling/callback syntax between the call failed and the unexpected response branches maybe? But it means that you can’t rely on await to delineate where round trips are happening at least in that case.
- thegagne 5y agoI think it’s because of the different actions you might want to take after the fetch. 1. Parse the data as json 2. Return it without parsing 3. Modify some other part of the response but never parse the body 4. Turn around and stream that body into another fetch without parsing it. Etc. parsing it and loading a large response into memory may not always be desirable so it must be explicitly done with await res.body.json().
- mcintyre1994 5y agoI agree that it might never be parsed/you might not want to, and that it shouldn’t be done implicitly. But I’m not sure why that requires await instead of just a plain function call to parse it explicitly.
- __jem 5y agoReally dislike active record style ORMs. Even if the entities are proxies w/ some magic (e.g. lazy loading), they should still read like plain records in the code, and be programmed with a data-first style. Because methods accumulate on these active record entities, I’ve found devs tend to treat them more “thingly” than just data projections. The user doesn’t save itself. It’s just a row in a database.
- mdavidn 5y agoI agree. The one thing that keeps bringing me back to ActiveRecord and ORMs like it is the Relation class. Being able to pass around and merge queries is great for organizing code and keeping concerns separate. For example, implementing pagination, user permissions, UI filtering, and tenant segmentation, all in the same query without these concerns depending on each other. Composable scopes on models is another joy. One convenient trick with Postgres is to define complex calculations as SQL views. Define an ActiveRecord model for the view, point some “summary” associations at it, and read it like a table.
- SomeCallMeTim 5y agoYeah, and we already have TypeORM in Node, which is an excellent ORM (despite some clear haters here in the comments). This is why Deno is a dead-end. We have tons of excellent solutions in the Node-verse, and they need to build everything up from scratch (or create ports that are "unstable and shouldn't be used in production" [1]). And it's not just the ORM that's interesting. It's the tooling that will connect, say, TypeORM or Prisma.io to GraphQL, so that you can throw up an API in a few lines of code, that means you're writing something like 1/100 the number of lines of code for equivalent or even superior functionality. [1] https://github.com/denolib/typeorm https://github.com/denolib/typeorm
- Possiblyheroin 5y agoYou can't yet have multiple where conditions seperated by an OR operator. I've been using this library for a side project and unfortunately I just don't think it's mature for production use cases yet. Hopefully it keeps maturing as it otherwise shows quite a bit of promise.
- vinkelhake 5y agoI've been using [1] which is SQLite compiled to WASM (what a weird world we're in now). It's got some limitations and caveats, but it's working well for my current modest needs. It's a pretty straightforward wrap of the SQLite API - no ORM. The advantage is that it doesn't depend on having anything installed. Just import and you're good to go. [1] https://deno.land/x/sqlite@v2.4.2 https://deno.land/x/sqlite@v2.4.2
- Sammi 5y agoI'd love to see a benchmark between using this and a natively compiled sqlite. Just to see how much performance is lost to this convenience, so I can judge if it would be worth it in a concrete project for me.
- mirekrusin 5y agoPersonally I prefer functional combinators like interfaces [0]. Js/ts have tagged templates which enhances those type of interfaces a lot. It gives access to full set of functionality of underlying database, not just common denominator of all used. It allows arbitrary compositions etc. [0] https://github.com/appliedblockchain/tsql/ https://github.com/appliedblockchain/tsql/
- phplovesong 5y agoDuring my years as a dev i have really started to dislike ORMs. They always fail in the end. SQL is universal, and transfers between languages and tech fields. This is why im pro-sql, and always try to avoid unnecessary abstractions. I have actually went back to writing pure SQL in files, and using those as params for whatever db engine i use, this makes it even possible to reuse the code in other projects (even its unlikely that you can use the exact same query, but just as a "it would work" in theory). For node based projects i have used and would probably still choose pg-promise (https://github.com/vitaly-t/pg-promise https://github.com/vitaly-t/pg-promise).
- gmac 5y agoAgreed on the appeal of sticking to SQL. I’ve written an alternative non-ORM for Node and TypeScript (which doesn’t separate out your queries): https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/
- threeseed 5y ago> SQL is universal No it's not. A small subset of it will work consistently across databases. But if you want to get the most of your database then in almost cases you will be working with proprietary SQL. And ORMs have the advantage of abstracting this SQL away for you allowing that you to work across databases if you need to.
- zoul 5y agoMeaning it’s vastly more universal than your ORM du jour.
- mozey 5y ago> And ORMs have the advantage of abstracting this SQL away for you allowing that you to work across databases if you need to In theory, in practise my experience is the oppose. It's easier to understand and tweak the SQL to work across DBs. You can easily diff and compare the SQL files. The ORM is another moving part, it adds convenience for simple queries, and complexity for anything advanced or non-standard.
- jakobdabo 5y agoAs a JS and async/await outsider, just looking at the README example, can anybody please explain what's the reason to have the await prefix syntax at all? At this rate it's going to be all over the place. If the function is asynchronous, what's the difference for the caller? Can't it just be omitted?
- soylentgraham 5y agoIf you omit await, the returned calue is a promise which you can keep for later, instead of waiting right now. Say you want to kick off something you know will take a while, do some ofher things (async or not), THEN wait for the original async operation. (Or even say, wait for multiple promises to finish)
- jakobdabo 5y agoThanks, I understand it, but my issue is that more and more libraries and functions are now asynchronous, so the await prefix is going to be everywhere. Maybe it should've been the other way around - when calling an asynchronous function you get the result by default, and can get the promise if you want (as it happens much less frequently): const res1 = func1(); // async or not, wait for the result const res2 = func2(); // async or not, wait for the result let res3_p = promise func3(); // async function, but we want the promise
- kaoD 5y agoIf a function is async it's because it is potentially long-running or expensive. I don't want that fact hidden. I don't find `await` particularly bothersome to write, and it explicitly tells me which calls are async and can be used in promise combinators or called non-blocking.
- jakobdabo 5y agoThanks, I guess that's a good reason.
- ilovwindows 5y agoORMs are unnecessary abstraction. Check out https://github.com/ludbek/sql-compose https://github.com/ludbek/sql-compose Tools like this are the future. It's so simple yet flexible enough to handle any complex queries. It scales infinitely.
- viraptor 5y agoQuery composing is probably 5% of the ORM framework. This is a valid thing to use. It's not an ORM replacement in any way.
- ilovwindows 5y agoI disagree. Query composing is probably 70% of an ORM framework. Rest are schema generation, serialization and validation. All of which can live outside the ORM.
- viraptor 5y agoMapping to actual objects. Type mapping. Merging requests over relationships. Transaction integration. Dealing with dirty markers and writebacks. All of those along with validation depend on the database and object formats. Those are why ORMs exist in the first place. If you take them out, what you have left is a repository pattern with some struct mapping helpers only. Which is fine if you want that, but you'd miss the "R" and the "O".
- kh_hk 5y agoIs the general consensus that we are just happy slapping an 'await' in front of instructions we want to execute sincronously, or I am missing some fundamental idea here?
- handrous 5y agoPretty much, yeah. It's yet another sign that JS/Node should have had a keyword to let async functions appear, to the calling code to act async, rather than requiring a keyword to stop that. IOW its idiom is backwards from what would be best for the programmer in the typical project. The other signs have been... every live codebase using every previous method of dealing with JS & node's async patterns. "Callback hell", the very common pattern of using promises to wrangle async code into acting synchronous, and now "await", comically, prefacing more async calls than not.
- brainless 5y agoEvery time we discuss an ORM project, someone is bound to complain about ORMs in general. I have a small suggestion: please try ORMs in different languages. A lot of the power of an ORM depends on the language. Your ORM may not be the same as my ORMs - Django ORM, SQLAlchemy, Pony ORM. Try them and you will know why. I will wait. From my limited understanding, the language needs to allow reflecting and manipulating your model definitions (like a model Class) which define the data model as a set of tuples (field name and field type, which is a representation of SQL type) into instances that hold data in the native types of the programming language and "magically" convert them to the SQL types. It usually falls under the realm of meta programming and is not exactly a first-class feature in many languages. I am totally not a language expert and perhaps did not articulate this well enough, but if you are curious just search a bit and try. Just my 2 Rupees.
- KptMarchewa 5y ago>I have a small suggestion: please try ORMs in different languages. I mean, I've done it and had entirely different experience. Starting from the entire premise of learning N different abstraction layers over one abstraction layer.
- smt88 5y agoI've used ORMs for 20 years in Java, PHP, C#, JavaScript, TypeScript, Python, and Kotlin. I have pushed code to production with at least 10 ORMs, possibly more. ORMs are a bad idea. They are a productivity killer. Do not use them. I also used to think I'd find a "good" ORM because the early magic is so exciting and efficient. But for anything beyond a toy or proof-of-concept, they are more cost than benefit. Some of them (e.g. TypeORM, Entity Framework) are literally not debuggable because they use some much configuration magic. Just avoid them. Write SQL in SQL (or a query builder that compiles to SQL).
- SomeCallMeTim 5y agoWow. See this other comment I wrote: https://news.ycombinator.com/item?id=27551288 https://news.ycombinator.com/item?id=27551288 TypeORM in particular is well designed and quite awesome. A huge benefit of TypeORM is that you get full static type support in all of your queries, including in the returned results. SQL results are effectively one-off dynamic type result piles that you need to validate by hand, and are insanely inefficient to code.
- nih0 5y agoNot to be too negative but I really appreciate Java's DataSources and other abstractions every time I see some python/node "connectors".
- markstos 5y agoSo, pick a database, use DenoDB and then use the lowest-common-denominator feature set of all the databases it supports. There's a great parable from almost two decades ago. Movable Type was a popular open source blogging platform that used an ORM and supported multiple database backends. Wordpress only supported MySQL. Remember Movable Type? I hacked on both and preferred working with Perl and PostgreSQL but the ORM layer was a pain to use. Thousands of other developers apparently agreed, as the Wordpress extension ecosystem thrived and Movable Type bombed.
- Aeolun 5y agoOf course. Developers experienced enough to see the benefits of and understand an ORM will likely not be working on your average Wordpress site.
- evanelias 5y agoInitial disclosure: I worked for Six Apart (makers of Movable Type) a dozen years ago, so maybe I'm still inadvertently biased, but I certainly try not to be. Wordpress won out for a number of reasons, mostly relating to licensing (Movable Type temporarily went non-FOSS at a critical moment in time), ease of hosting (PHP vs Perl), ease of dynamic content (MT generated static pages), and better company product focus (MT's parent company tried doing too many things at once and ran out of money). I say this as someone who doesn't love ORMs, so don't get me wrong here, but I've never seen a serious analysis that ranked MT's ORM layer anywhere as a factor in WP's dominance. The vast majority of MT users used MySQL anyway, and MT's ORM definitely had first-class support for MySQL. In 2010, MT 5 dropped support for Postgres and SQLite entirely. I was in Six Apart's Services org, mostly developing MT plugins for larger MT users, but also occasionally WP plugins as well. Personally I quite liked MT's ORM at least circa MT 4.x, and found that developing MT plugins was far more enjoyable than WP plugins at the time. (fwiw I was equally fluent in Perl and PHP, so that wasn't a factor.) MT had a very powerful plugin system that, combined with Perl's ability to "monkey patch", essentially allowed you to hook into pretty much any part of the CMS or page generator that you wanted. Back when MT was popular, it had a thriving extension ecosystem that very much rivaled Wordpress's, so it is simply not accurate to say MT bombed due to a poor extension ecosystem. Yes, eventually WP's ecosystem was massively larger, but that also simply tracks with size of PHP developer community vs size of Perl developer community over time.
- tgeorge 5y agoI've played with SQLAlchemy and Django's ORM in the past with Python but as of late I have been taking a liken to Eloquent while working with PHP's Laravel. It's always weird trying an ORM when coming from native SQL but I think eloquent might of found a happy medium as it seems flexible to me. https://laravel.com/docs/8.x/eloquent https://laravel.com/docs/8.x/eloquent
- clivestaples 5y agoI am just discovering Laravel and years of Rails, React, etc and it's been a lot of fun. At first glance, DenoDB also seems to have a good level of abstraction.
- ttfkam 5y agoIf you want an ORM, use GraphQL. It has the one thing missing in all other ORMs: it's a spec, not an implementation. Don't like one vendor, swap in another without breaking upstream services. Seriously, folks really underestimate the benefits of a published spec over a sea of inconsistent implementations. Learn one ORM, you're SOL when the new team uses a different one. Time to start over again. Got a bug in your ORM? Hope they fix it, because migrating to another ORM is more painful than migrating SQL syntax. Need to work around the ORM? Why do you even have an ORM? Can you imagine browsers if they didn't standardize on HTTP? Tied to a particular vendor's server or having ten different wire protocols competing? That's where ORMs are now without a spec. It's insanity.
- dalu 5y agoOk but what is Deno?