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

81–90 of 124 posts

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

#81

Post by mqus »

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…

What do you think about ORMs like Androids Room[1], where you do specify your own queries with sql (by annotating abstract methods) and can bring your own model and the ORM creates the database schema in the database and gives you access to easy insertion methods.

I don't know how Room does it but darts floor library(which is similar)[2] then generates the code that is necessary, in addition to a very slim runtime layer for managing update events. I find that this is also an approach which in some ways only does half the work for more flexibility, while still depending on a fixed database schema.

[1] https://developer.android.com/training/data-storage/room

[2] Shameless plug: https://github.com/vitusortner/floor

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

#82

Post by benatkin »

racedude wrote: post #4
capnorange wrote: post #3

still yet to find an ActiveRecord equivalent for javascript.

What about this? https://github.com/typeorm/typeorm/blob/master/docs/active-r... (Forgive me if this isn't what you are looking for, not super familiar with ActiveRecord myself, just recalled seeing that yesterday!

I like TypeORM but have passed on it for now because of this potential sql injection issue: https://github.com/typeorm/typeorm/issues/3740 I have passed a field to order_by() from the user in Django before. I would be more likely to use a dict now, but I shudder at the thought of accidentally creating an SQL injection bug because I expected to be protected by my ORM.

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

#83

Post by Jarwain »

exevp wrote: post #15
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…

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…

We actually went with knex/objection specifically because there was a planned migration to postgres that it would simplify, and we'd be able to migrate different databases in stages.

Plus it was integrated into feathers, and knex simplifies hook-based query building logic.

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

#85

Post by wayneftw »

I started using Objection.js and Knex last year and I think it might be the best ORM I've used on any platform.

There's no way I'm going back to writing raw queries. If I did that, eventually I'd rewrite Knex.

If and when I need a raw query, I can already do that with Knex.

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

#86

Post by 2color »

joshmanders wrote: post #71
2color wrote: post #60

Earlier quoted context omitted.

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..

I think this article does a good job of comparing the two if you're familiar with TypeORM: https://medium.com/better-programming/prisma-vs-typeorm-60d0... which compares the two.

Most of exevp's comment about the Prisma schema are a non-issue given an understanding of the value it provides. But I can understand the reluctance to learn yet another DSL. But in my experience, if you've worked with relational databases, it's a breath of fresh air to be able to define your database schema with it.

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

#87

Post by cryptica »

History keeps repeating itself. People never seem to learn anything. At first there were no ORMs, then ORMs became extremely popular and everyone was using them, then everyone learned that ORMs were a very bad idea and we stopped using them, vowing never to make the mistake again... And here we are again in 2020, ORMs are back. They will be in for a while, then out again, then in again....

Same with statically typed vs dynamically typed. First everything was statically typed, then dynamically typed (interpreted) languages gained popularity, developers LOVED not having to wait for the compiler to finish to test their changes; this was a revolution... Now again, we're going back to statically typed languages, everyone uses clunky bundling and transpilation tools which add bloat and everyone is happy to wait 20 seconds to a minute for their code to compile.

Every few years, developers believe the opposite of what they believed before and the consensus seems to be close to 100% every time. It's ridiculous.

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

#88

Post by exevp »

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 understand where Prisma is coming from with the custom DSL: they want to guarantee type safety and therefore need to know exactly the structure of the types the result set is supposed to be mapped to.

In most other languages you'd shout "reflection" but unfortunately, there is no such thing in TS. Hence the custom DSL so you know, while parsing, what the structure of the type is.

I'm just asking myself: why invent the custom DSL for that? You could just use babel to parse TS types. Sure babel is quite the dependency but in a node environment, that wouldn't be a bigger concern to me then inventing a custom DSL instead.

You could even use TS decorators to add more metadata like sequences and (foreign) keys to the TS types.

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

#89

Post by ryanmarsh »

This is very nicely done, kudos to the author. I'm sure many will find this useful.

Personally I've gotten away from using SQL RDBMSs. Since I primarily build on AWS I use DynamoDB but the same principle would apply elsewhere. I like to store data in the format that best supports the read model. Event sourcing allows me to change the structure of the read model, or add new read models, or vary strategies depending on data, as needed. I like that I no longer have the impedance mis-match of the normalized relational model.

It was a big jump to make, and I had to unlearn a lot. I'm not dismissing the value of RDBMSs at all. I love them, especially star schemas for analysis. I just want to share that it's ok to not use an relational model for your transaction store.

Post reply on HN