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

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

github.com

Post reply on HN
Print view View original

41–50 of 108 posts

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

#41

Post by eglintondust »

notsylver wrote: post #27
fourseventy wrote: post #8

I've come to the conclusion that ORMs are good for simple queries like User.find_by(email: "john@snow.com"), but once you get beyond that you are better off just writing sql.

It might be because I'm not used to SQL, but I've found the opposite. Writing a large query with lots of conditions (eg, if the user is signed in, hiding content they've blocked) is miserable without an ORM that can build the query and map the results. I don't like ORMs for lots of reasons but I find them a necessary evil. How do you deal with that in plain SQL, when a query can look completely different depending on…

A good query builder is more important than ORM imo. That's what I like about sqlalchemy. The query builder pretty much maps 1:1 to SQL and you can use it with or without the ORM mapping. Most of my projects have a mix of both along with plain SQL for some of the meatier queries.

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

#43

Post by tilyupo »

sigseg1v wrote: post #37

Cool project! Looking at the docs, for example the pg connector, I couldn't easily find information about how it parameterizes the queries built through method chaining. For example, if I run .filter(user => user.name.eq(unsanitizedInput)) I am presuming that the unsanitizedInput will be put into a parameter? For me, using ORMs on a team that may include juniors, that is one of the key things an ORM provides: the abi…

Qustar parametrizes all queries by default, so it's immune to SQL injections. I'll add info about that with examples to the docs, thank for the feedback!

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

#44

Post by suchar »

hahn-kev wrote: post #32
_1 wrote: post #28

[flagged]

Yes, in my opinion the biggest problem with straight SQL is dynamic filters. It easily becomes a huge mess and that filter is only good for that one query, sure you can layer on stuff to make it better, but then you might as well use a library.

Sometimes you can avoid writing multiple queries with different filters by creating single parameterized query with conditions like:

    WHERE (name LIKE :name OR :name IS NULL)
      AND (city = :city OR :city IS NULL)
      AND ...
By no means it is perfect, but can save you from writing many different queries for different filters while being easy to optimize by db (:name and :city are known before query execution).

Still, I prefer explicit SQL in webservices/microservices/etc. the code and its logic is "irrelevant" - we care only about external effects: database content, result of a db query, calls to external services (db can be considered to be nothing more than an external service). And it's easier to understand what's going on when there is one less layer of abstraction (orm)

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

#45

Post by tilyupo »

v_b wrote: post #33

It is dope, please continue on this. I used to work with TypeORM and really missed using EntityFramework. That actually led me to switch to Mongo (Mongoose). I'm really looking forward to this project!

I've big plans for Qustar, thanks for kind words!

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

#48

Post by evilduck »

notsylver wrote: post #27
fourseventy wrote: post #8

I've come to the conclusion that ORMs are good for simple queries like User.find_by(email: "john@snow.com"), but once you get beyond that you are better off just writing sql.

It might be because I'm not used to SQL, but I've found the opposite. Writing a large query with lots of conditions (eg, if the user is signed in, hiding content they've blocked) is miserable without an ORM that can build the query and map the results. I don't like ORMs for lots of reasons but I find them a necessary evil. How do you deal with that in plain SQL, when a query can look completely different depending on…

It's like a bell curve for me personally. The things I do with databases between the 25th and 75th percentiles of query complexity fit into an ORM or query builder tool nicely. These also tend to be the bulk of what I need. But those tools add more overhead to the effort of writing simple <25th percentile SQL (like small single-table queries), and then end up being wholly inadequate for the complexity above the 75th percentile, where the library often doesn't have good representation or documentation for the complex things a database can actually do for you in advanced use cases (leading you to do a less efficient similar operation in your programming language), or they try to be too generic to many databases and then aren't able to provide anything that might be specific to Postgres which leads you back to writing raw SQL again.

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

#49

Post by [deleted] »

tilyupo wrote: post #22
Eric_WVGG wrote: post #19

I love your syntax for joins and unions! A bit puzzled by why the connector slots into the query, instead of the query slotting into the connector, given that it’s the connector that’s actually doing the work. I.e. ‘connector.fetch(query)‘ … rather than… ‘query.fetch(connector)‘

It was more of an ergonomics choice. To me it seems like it's more readable to write `await users.filter(user => user.id.eq(42).fetch(connector)` instead of `await connector.fetch(users.filter(user => user.id.eq(42))`. But I might be wrong, your idea makes more sense from logical perspective.

[deleted]
Post reply on HN