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

31–40 of 108 posts

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

#31

Post by enobrev »

_1 wrote: post #28

[flagged]

In general, I tend to prefer straight SQL, but for a project I expect to maintain over time, I like having an orm. To go further, I like to write and maintain my own orm(s), that auto-generate the classes and functions that I'll be using.

This is mostly for making sure my code is up to date with the database. A migration _requires_ a code-change due to the orm code-gen and thus i can't deploy the migration until I ensure my codebase is ready for it

Overall, I would much prefer native SQL support in whatever language I'm working in. But a light ORM tends not to be a terrible trade-off.

Also I like this style of orm because sometimes the order of definining SQL is annoying to me. I prefer to start with the "from" and the joins, then add the conditions, and finally, the columns, which likely reference the other parts and thus make more sense at the end.

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

#32

Post by hahn-kev »

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

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

#37

Post by sigseg1v »

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 ability to know for sure that a query is immune to SQL injection.

If you had more examples on the connectors of queries like this, and also maybe some larger ones, with the resulting SQL output, I think that might increase adoption.

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

#38

Post by szundi »

_1 wrote: post #28

[flagged]

If you are tossing around documents or objects with metadata etc, want to remain open for future features and schema modifications, having just 100k users not 100m - so so so comfortable.

AFTER you learned to use it hahahhahahhhhahha - evil laughter.

Ps I love hibernate.

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

#39

Post by [deleted] »

v_b wrote: post #29
layer8 wrote: post #14

The API doesn’t really look “array-like”.

When I think of "array-like," I envision using brackets [i]. But the OP isn't wrong; all the methods used to construct the query also function as instance methods of arrays in both JavaScript and TypeScript.

[deleted]

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

#40

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.
Post reply on HN