Live data from Hacker News

Show HN: Node.js ORM to query SQL database through an array-like API

github.com

91–100 of 108 posts

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#91

Very nice! Almost everyone I know misses Entityframework if they ever worked with it and similar ergonomic ways in other languages (clojure/cl). Entityframework has it's downsides, but it's so nice to develop with. I don't mind (and often use SQL), in fact, since no longer using C#, I find myself using SQL more often than ORMs as everything is so ... clumsy... compared to entityframework. Continue doing the excellent…

One of my main reasons for using C# is entity framework and Visual Studio itself.

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#92
post #84

Earlier quoted context omitted.

> manage migrations I feel like it is one of their major drawbacks. But I'm mostly working maintenance so what I usually see are databases outliving many applications and my view will differ from greenfield project people. Your ORM is tied to your app. Tying your database to your app through your ORM is IMO an error. Managing schema change in your application is even worse. Database and their schema should be indepen…

How do you manage database migrations then? Are they in Git repository? Genuinely curious.

Yes, like any other piece of your system.

It can feel overkill when you have one app with its code repository, infra repository and now schema repository. But most people are not doing microservices so the database is central and used by multiple applications. Then one more repository, which you'd want DBAs to handle, is nothing.

Also, migrations should only go up and be non destructive.

The main problem and I think it is one of the current open ones for the gitops / CD ecosystem is managing which versions of your software are compatible so you know what can be running together or not. Package management but for your whole software architecture.

All this are personal opinions and I'd be happy to have to change it if presented with good arguments against it.

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#93
post #89
post #85

I never use orms and don’t find them appealing, but one thing I do with my sqls may interest you. I always wrap .query(…) or simply pass its result to a set of quantifiers: .all(), .one(), .opt(), run(), count(). These assert there’s 0+, 1, 0-1, 0, 0 rows. This is useful to control singletons (and nonetons), otherwise you end up check-throwing every other sql line. One/opt de-array results automatically from T[] to T…

Interesting, it throws an error if result rows don't match expected quantity?

Yes, and together with .in_transaction(cb) wrapper it also rolls everything back. Sadly SQL itself doesn't have something like ASSERT ROWCOUNT , cause it's such an obvious check, especially in destructive ops. LIMIT exists, but it is silent and quirky with non-SELECTs.

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#94
post #59

Nice, looks promising. How does this compare to drizzle? Context: We've had a lot of ORM frameworks come and go in node.js - sequelize, typeorm etc, but none of them have really caught on. Things have been changing a lot lately after typescript took over, so we've seen a bunch of ORMs take off that give you a really good typescript experience. So, the juggernaut in this space is of course prisma, which is super expre…

Hmm. I might be wrong as I haven't used Drizzle, just read the docs, but isn't Drizzle just like Prisma? That's really not the same as this. I find Prisma at least one of the most terrible things I ever worked with in my life ; the rigidity (which I guess is the arrogance of the devs which they call opinionated; their right but he), the weird querying dsl, the terrible tooling. Just checked 'Drizzle queries' again an…

[flagged]

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#98
post #77

Earlier quoted context omitted.

Performing a query with EF is able to do stuff that can't be done with `IEnumerable`. So that a filter()/.Where() can actually generate a WHERE clause instead of looping over every record.

Yes of course it generates the corresponding SQL and don’t iterate over the table. But in the framework’s code, IQueryable implements IEnumerable, it’s just a totally different implementation but for the developer it’s 100% the same API and so any IQueryable can be used where a IEnumerable is expected.

This is a hazard that trips people up commonly. If you use an IQueryable where an IEnumerable is expected, it will use brute-force iteration semantics, and not do things like generating a WHERE clause. Linq provides similar extension methods for both interfaces, but you need to be sure your call resolves to the right interface, otherwise you'll end up doing things like pulling the whole table into memory.

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#99
post #71

My take on this is that it's not always the best idea to abstract-out SQL. You see, the SQL itself is too valuable abstraction, and also a very "wide" one. Any attempt to hide it behind another abstraction layer will face these problems: - need to learn secondary API which still doesn't cover the whole scope of SQL - abstraction which is guaranteed to leak, because any time you'll need to optimize - you'll need to st…

This is one of 4 reasons why I'm building pg-nano [1] and honestly the main catalyst. The other 3 reasons are: I still want to call my Postgres functions from TypeScript in a safe manner; I want declarative schemas with generated migrations; and I want the ability to write compile-time plugins that can generate SQL or TypeScript through introspection.

It's not released yet, but give it a look :) (v0.1 is almost done)

[1]: https://github.com/pg-nano/pg-nano

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#100
post #71

My take on this is that it's not always the best idea to abstract-out SQL. You see, the SQL itself is too valuable abstraction, and also a very "wide" one. Any attempt to hide it behind another abstraction layer will face these problems: - need to learn secondary API which still doesn't cover the whole scope of SQL - abstraction which is guaranteed to leak, because any time you'll need to optimize - you'll need to st…

ORMs are usually used for speed until it's time to optimize with writing the SQL.

Some ORMs have def have some more experience getting optimized in delaying the need to optimize the query, indirectly, or directly by rewriting it.

ORM with a bit of SQL might still be less work than using a nosql db and trying to make it relational, but not.

Post reply on HN