Looking 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.)<p>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.<p>Anyways, kudos to both communities. You've done a lot!<p>- [1] <a href="https://deno.land/x/postgres@v0.11.2" rel="nofollow">https://deno.land/x/postgres@v0.11.2</a><p>- [2] <a href="https://deno.land/x/mysql@v2.9.0" rel="nofollow">https://deno.land/x/mysql@v2.9.0</a><p>- [3] <a href="https://github.com/brianc/node-postgres/tree/master/packages/pg" rel="nofollow">https://github.com/brianc/node-postgres/tree/master/packages...</a><p>- [4] <a href="https://github.com/mysqljs/mysql" rel="nofollow">https://github.com/mysqljs/mysql</a>
Every time we discuss an ORM project, someone is bound to complain about ORMs in general.<p>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.<p>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.<p>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.
You 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.<p>Hopefully it keeps maturing as it otherwise shows quite a bit of promise.
I hate ORMs with the fury of a thousand suns.<p>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.<p>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.<p>Currently I'm looking at pg-types because you just write SQL and it just helps by making some TypeScript types for you.<p>(I have used ORMs in C#, PHP, and JavaScript and I hate all of them).
I'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.<p>[1] <a href="https://deno.land/x/sqlite@v2.4.2" rel="nofollow">https://deno.land/x/sqlite@v2.4.2</a>
At 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 ...
Personally 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.<p>[0] <a href="https://github.com/appliedblockchain/tsql/" rel="nofollow">https://github.com/appliedblockchain/tsql/</a>
Really 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.
If 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.<p>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?<p>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?<p>That's where ORMs are now without a spec. It's insanity.
I'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.<p><a href="https://laravel.com/docs/8.x/eloquent" rel="nofollow">https://laravel.com/docs/8.x/eloquent</a>
During 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.<p>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).<p>For node based projects i have used and would probably still choose pg-promise (<a href="https://github.com/vitaly-t/pg-promise" rel="nofollow">https://github.com/vitaly-t/pg-promise</a>).
I really recommend to check out his channel: <a href="https://www.youtube.com/c/eveningkid" rel="nofollow">https://www.youtube.com/c/eveningkid</a><p>One of the lower subscribed well produced tech channels I've seen in a while.
So, pick a database, use DenoDB and then use the lowest-common-denominator feature set of all the databases it supports.<p>There's a great parable from almost two decades ago.<p>Movable Type was a popular open source blogging platform that used an ORM and supported multiple database backends.<p>Wordpress only supported MySQL.<p>Remember Movable Type?<p>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.
ORMs are unnecessary abstraction.<p>Check out <a href="https://github.com/ludbek/sql-compose" rel="nofollow">https://github.com/ludbek/sql-compose</a><p>Tools like this are the future. It's so simple yet flexible enough to handle any complex queries.<p>It scales infinitely.
Is 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?
Not to be too negative but I really appreciate Java's DataSources and other abstractions every time I see some python/node "connectors".
As a JS and async/await outsider, just looking at the README example, can anybody please explain what's the reason to have the <i>await</i> 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?
The link and title made it seem like something official from the Deno developers but it's just a mirror for <a href="https://github.com/eveningkid/denodb" rel="nofollow">https://github.com/eveningkid/denodb</a>