Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

Post by lucideer » Thu, Sep 03, 2020, 2:13 PM UTC

CoffeeDregs wrote: post #34

sql"SOME SQL"; This looks to be a "tagged template": https://basarat.gitbook.io/typescript/future-javascript/temp... . I'm a TS user but hadn't seen that feature before. AFAICT, the library is using a side-side-side-feature (tagged templates) of TS as the core abstraction [1]. Impressive. Might be a little brittle in the face of significant SQL or query composition? Anyhow, I'm a heavier-ORM user but that's impressiv…

Post by midrus » Thu, Sep 03, 2020, 2:15 PM UTC

exevp wrote: post #26

midrus wrote: post #11

All these things fall short the moment you need real "production" features, such as reliable migrations (writing them by hand? no thanks. Outsourcing to another library like knex? no thanks), transactions, community support, relationship/nested/join queries without a ton of boilerplate and being battle tested. So far, the best thing I've found in the node ecosystem is Prisma [1], and it's better than the alternatives…

I find that most of the production features you mentioned are actually more difficult using a fat ORM. How many hours have i wasted figuring out how i can write and map some complex joins or aggregation query with ? Would have been a 3 minute task if all i had to write was just SQL ... Plus i have a hard time seeing the benefit of Prisma. You are learning an entirely new DSL just to define your schema - which actuall…

Post by midrus » Thu, Sep 03, 2020, 2:19 PM UTC

dathinab wrote: post #27

midrus wrote: post #11

All these things fall short the moment you need real "production" features, such as reliable migrations (writing them by hand? no thanks. Outsourcing to another library like knex? no thanks), transactions, community support, relationship/nested/join queries without a ton of boilerplate and being battle tested. So far, the best thing I've found in the node ecosystem is Prisma [1], and it's better than the alternatives…

> reliable migrations My experience is that libraries which do handle that for you automatically do a really bad job at it. Writing it by hand and most important thoroughly testing it and trying to avoid doing any changes needing complex migrations is in my experience more reliable on the long run. EDIT: removed inappropriate caps usage

Post by Seb-C » Thu, Sep 03, 2020, 2:22 PM UTC

bakedbeanz wrote: post #28

Seb-C wrote: post #22

Earlier quoted context omitted.

> reliable migrations (writing them by hand? no thanks. Outsourcing to another library like knex? no thanks) IMHO, "real production features" means also caring about the long term maintenance, performance and reliability of the data. My experience with ORMs (especially ActiveRecord patterns) is that it always becomes a mess once you reach a certain level of complexity. It is very fast to get started, but gets slower…

Interesting, then what is your alternative? It seems like hand-rolling all of your migrations would be an enormous pain on larger projects.

Post by exevp » Thu, Sep 03, 2020, 2:25 PM UTC

Seb-C wrote: post #40

exevp wrote: post #15

Earlier quoted context omitted.

tl;dr: thank god it finally has been done. Long version: i've been seriously frustrated with the state of ORM (in Javascript in particular) for years. Javascript ORM are nice and handy if all you're doing is simple CRUD stuff. If you're starting with more complex relational queries (we're using an RDBMS so why wouldn't we?) you quickly reach the limits of what the ORM can map. If you start doing more complex aggregat…

Thanks for your comment! As you say, one of the main arguments for query-builders is allowing the support of different RDBMS. But in my experience it not only never happens, but the abstraction is never perfect and makes any unsupported edge case impossible to solve without hacking around. There is so much that can be done with SQL that would result in a mess of inefficient spaghetti code...