4 ms·
> Much less boilerplate than any ORM tool generates. I disagree. The SQLAlchemy query language is very nice, for instance. > That depends how expressive is th
by mercurial 12y ago
> Much less boilerplate than any ORM tool generates.
I disagree. The SQLAlchemy query language is very nice, for instance.
> That depends how expressive is the application language's meta-programming capabilities.
Certainly, but metaprogramming doesn't necessarily rhyme with readability.
> The thing is, if I have to fine-tune the ORM generated SQL for optimal performance, its value diminishes.
Of course. However: the SQL generated will be fine for the majority of queries. What's going to bite is the use of lazy collections. For complex queries, you may want to fine-tune it by hand (though not necessarily).
That said, I rather agree that ORMs are best avoided. The existence of lazy collections makes it very easy to turn what ought to be a straightforward, fast query into something slow. What I'd like to work with is a query builder for select/insert, and avoid magic, even at the cost of creating by hand awkward structures like PersonWithAddress and PersonWithAddressAndBankAccount.
- sanderjd 12y agoYeah, query-building languages with good composability are a sweet-spot. In ruby, there is arel, which describes itself as "a relational algebra", rather than an ORM and is actually how activerecord, which is absolutely an ORM, is implemented. It's possible, even easy, but not particularly idiomatic, to drop down into using arel for more complex queries.