Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've enjoyed the ORM in adonisjs: https://docs.adonisjs.com/guides/models/relationships#preloa...

Having used it on an actual product and dealing with some of the pain points, it's my go-to since the typescript version (v5) came out.

The ORM uses Knex.js internally, which is very simple to drop into if you just want a query builder. Having Knex be accessible also makes it simple to just write your query in plain sql as well, or as the Lucid ORM has available, just fragments of your query (say the join statement) as raw sql: https://docs.adonisjs.com/reference/database/query-builder#w...

Along with debugging, printing out the sql, and support via the Adonisjs REPL "Ace", it makes for a very nice experience.



These are more akin to Dapper which is a thin layer on top of SQL. Currently I use Prisma for JS, it's a bit better, but if you haven't used EF then you probably don't know what you're missing.


I've used EF quite a bit in the past. While there may be some features missing, Lucid an ActiveRecord implementation, which I would figure would fall into the "ORM" category.

Which features would you say are the key ones that make Lucid seem more like a query mapper (Dapper, Knex) than an ORM (ActiveRecord, EF)?

Specifically, in my Adonis projects, I'm mostly working with the Model objects through the ORM methods, and only dropping to Knex/SQL when necessary (complex CTE, etc). Since it's such a Model-centric seeming way of development, it naturally seems like an Object-Relational Mapping to me.


Context tracking - selecting multiple entities, updating and pushing them back to the db.

Selecting complex dtos, this isn’t query building. A lot of magic turns this into sql.

    TopPaidMayors = Cities
        .where(c => c.state.govoner.party ==‘dem’)
        .select(c => 
            c.name, 
            highestPaid = c.mayors
                .orderByDesc(m => salary)
                .take(10))
        .orderBy(c => highestPaid.First().salary)


Well you put a fairly normal select query there, which is can be accomplished in Lucid as well. Additionally change tracking exists since it's an ActiveRecord implementation.

It's not all magic as well. Looking into the internals of EF, ActiveRecord, Hibernate, or other ORMs reveal patterns that once familiarized can help reason about the behavior of complex queries. I only state this to try to work against the commonly found wisdom of "big frameworks are magic" that tends to scare away learning developers from hoping to understand them.

There are intersections and disjunctions of feature sets between the various ORMs, with some features for EF still only available via extensions (or nonexistent). I don't think this makes the Lucid ORM any less of an ORM.

Again, I like EF Core. I simply think that as far as node-based ORMs go, that Lucid is the one I've had the best experience with, so wanted to highlight it.


Query builders are a thin wrapper on raw sql. Real ORMs that understand the relations between objects are not.

There are a ton of joins and sub-selects in that query. 8 very succinct lines. Can you do anything close in Lucid? I don't think so.


Well I've put sources and links to multiple pages about the ActiveRecord implementation. The Lucid documentation for the ORM "query building" (which it's the same in EF, LINQ has "Integrated Query" in the name) does track entities and subentities, which is how you can query things update them, then later call `.save()` to persist them back to the database.

However, you seem set on making this a combative conversation rather than a collaborative discussion, so I'll end my participation here.


I had hoped you'd put some actual code in either of your last two replies.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: