21–30 of 108 posts
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.
I think Qustar is closer to a query builder than ORM tbh. You can compose arbitrary queries using it.
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)‘
But I might be wrong, your idea makes more sense from logical perspective.
why is this arbitrary property desirable?
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.
When your queries become very complex having a good ORM like SQLAlchemy in Python is a life-saver.
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.
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 the variables?
The API doesn’t really look “array-like”.
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.
[flagged]
Why SQL itself isn't designed to composable, and why we are happy with that remaining the status quo, will remain one of life's mysteries.