Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

71–80 of 124 posts

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

#71

Post by joshmanders »

2color wrote: post #60
exevp wrote: post #26

Earlier quoted context omitted.

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…

Thanks for sharing your thoughts about Prisma. > Plus i have a hard time seeing the benefit of Prisma Prisma is supposed to improve your productivity and confidence when working with a database. It does so with a strong focus on type safety. Most ORMs and query builders in the Node.js/TypeScript ecosystem do not provide the level of type safety that Prisma does. For example in a blog with users and posts (1:n) queryi…

I have this same stuff in TypeORM but don't have the DSL issues that exevp mentioned..

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

#72

Post by blaufast »

I think its funny that 'opinionated' could be considered a virtue. I'm imagining a charity that uses 'opinionated' to describe itself, or even worse, a person. Even Apple, a brand famous for its strong design stances, does not use that word as a description of its values.

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

#73

Post by [deleted] »

Seb-C wrote: post #2

For a long time, I have been frustrated with the state-of-the-art about the existing ORMs. I like things to be simple, but somehow all ORMs seems to be bloated and overcomplicate a lot of things. When designing a new project, I have been trying to find a more satisfying design while avoiding the existing ORMs. I especially wanted to use proper SQL rather than reducing it's syntax to fit it in another language. This i…

[deleted]

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

#74

Post by WkndTriathlete »

Dragory wrote: post #62

It seems you cannot load relationships for a collection of entities easily without N+1 queries, unless I'm missing something. Based on the many-to-many section of the docs ( https://github.com/Seb-C/kiss-orm#many-to-many ), I would have to load relationships for each entity separately, and then if they have further nested relationships, run a query for each again. The subsequent section also mentions eager loading is…

Agreed on the N+1 query problem, but I'm a bit mystified why people still choose ORMs for any projects with even a moderate level of database complexity. When using a straight SQL layer (JDBC or the basic features of KISS-orm) the query is in SQL form and the performance characteristics of the query are obvious from the query or can be analyzed easily by taking the query and running it through the database's query analysis tools. Using an ORM just adds extra steps: instead of optimizing a query in SQL, the query needs to be optimized using directives or methods or annotations that the ORM provides in the hope that the SQL that is ultimately generated is efficient; that is, we're programming the ORM which programs the database instead of just programming the database. Why bother with the extra step? With modern programming languages there really isn't that much extra boilerplate to implement the DTOs for straight SQL and it usually results in code that is a lot easier to maintain and extend in the examples I've seen.

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

#75

Post by gmac »

Seb-C wrote: post #2

For a long time, I have been frustrated with the state-of-the-art about the existing ORMs. I like things to be simple, but somehow all ORMs seems to be bloated and overcomplicate a lot of things. When designing a new project, I have been trying to find a more satisfying design while avoiding the existing ORMs. I especially wanted to use proper SQL rather than reducing it's syntax to fit it in another language. This i…

My own TypeScript non-ORM, Zapatos, shares much of the same design philosophy (and indeed a sql`...` tagged template function): https://jawj.github.io/zapatos/

Previous discussion: https://news.ycombinator.com/item?id=23273543

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

#76

Post by string »

midrus wrote: post #44
string wrote: post #24

Earlier quoted context omitted.

I love Prisma and am a huge fan of Nexus[1] in particular. But it's interesting that you mention transactions as Prisma does not yet support long running transactions[2]. I have a side project that I've been working on for a little while, but I haven't touched it in months as I'm waiting on LRT support. Prisma is being very actively developed though as far as I can see, so I'm confident that there will be a solution…

Because to me, long running transactions are not something that should be done so lightly. A transaction is expensive for the database, so interpolating transactions with requests to external systems, other databases, etc is a bad idea from the get go to me. Just write down what you know at the moment, and update when you have the result, or use a small CQRS implementation for that specific use case. It is more relia…

I'm no expert when it comes to transactions or databases in general, so excuse my ignorance, but it seems to me an API to perform extremely simple transactions like the one outlined in that issue (no external systems or other databases involved) would be a very basic requirement for many projects?

Been "hanging out" in the Prisma discord and reading through issues for a while and it comes up quite a lot. It doesn't seem anyone has come up with a simple/viable workaround so far.

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

#77

Post by gnud »

midrus wrote: post #70
dgellow wrote: post #54

Earlier quoted context omitted.

1. create a "schema_version" table 2. have a unique, incremental migration ID in each migration filename 3. apply them one by one in order depending on the current schema_version from the target environment, and update the schema_version accordingly 4. rollback the transaction in case of error, otherwise commit and enjoy your updated schema I used golang-migrate/migrate in production for the past 3 years to do exactl…

And I assume you mean all of this is easier to do, safer, takes less effort, has more documentation, is more tested and proven and will be easier to understand by a new joiner after the one that wrote it left than using an existing, popular solution? Sorry, I disagree.

Just use Dbup [1] if you're a .net shop, and flyway [2] otherwise.

They are both existing, popular solutions that helps you organize your plain SQL migration scripts.

1: https://dbup.readthedocs.io/en/latest/ 2: https://flywaydb.org/

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

#78

Post by rubber_duck »

midrus wrote: post #45
dathinab wrote: post #27

Earlier quoted context omitted.

> 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

Tell that to the Django ORM. I've used it in really big projects, for really big companies and it never failed on us. As I said in another thread, the problem is not writing the SQL. The problem is everything else after you have written it (applying on deploy, automating for other's dev envs, rollback, etc)

>As I said in another thread, the problem is not writing the SQL. The problem is everything else after you have written it (applying on deploy, automating for other's dev envs, rollback, etc)

What's wrong with migration managers ? They handle all you mentioned just fine. The only problem I've seen with this approach were when working on a team that didn't have proper CI flow, then it was possible for people to check in bad migrations and screw up branches, etc.

I've worked with both approaches in multiple languages, and frankly I prefer the no-magic migration manager approach.

Migrations automatically generated from model also mean your DB is tied to your app, which I'm not a fan of, if anything the reverse should be true, and the fat model approaches of rails are terrible IMO (I haven't used Django for anything serious in over 10 years so I don't remember how fat their model layer is - I know it has enough metadata to generate the admin CRUD but don't remember if it also encourages having logic on models).

The best solution I've seen is F# which uses dynamic type providers (basically compiler plugin) to auto-generate models from DB/schema at compile time, and yesql in clojure (clojure being dynamic and built arround working with data using SQL results inside of it is natural and amazing).

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

#79

Post by dgellow »

midrus wrote: post #70
dgellow wrote: post #54

Earlier quoted context omitted.

1. create a "schema_version" table 2. have a unique, incremental migration ID in each migration filename 3. apply them one by one in order depending on the current schema_version from the target environment, and update the schema_version accordingly 4. rollback the transaction in case of error, otherwise commit and enjoy your updated schema I used golang-migrate/migrate in production for the past 3 years to do exactl…

And I assume you mean all of this is easier to do, safer, takes less effort, has more documentation, is more tested and proven and will be easier to understand by a new joiner after the one that wrote it left than using an existing, popular solution? Sorry, I disagree.

It’s definitely tested and proven, that’s a very common approach (not this specific migrate tool, but the general pattern). It’s simple to setup and only require standard SQL (or whatever your DB is using), has almost no moving parts, and is as stable as it can be.

I’m not saying it’s easier than other solutions, that’s not really a criteria I personally care about. But it is stable, simple, relatively easy to maintain, using standard tools, reliable.

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

#80

Post by dgellow »

peburrows wrote: post #64
dgellow wrote: post #54

Earlier quoted context omitted.

1. create a "schema_version" table 2. have a unique, incremental migration ID in each migration filename 3. apply them one by one in order depending on the current schema_version from the target environment, and update the schema_version accordingly 4. rollback the transaction in case of error, otherwise commit and enjoy your updated schema I used golang-migrate/migrate in production for the past 3 years to do exactl…

So... do pretty much exactly what ORMs with migration support already do for you?

Yes, the point is that you don’t need an ORM to manage migrations.
Post reply on HN