3 ms·

One thing you get with a good ORM is composability, though. Trying to build dynamic SQL queries with raw strings is a nightmare. Another, less useful property,

One thing you get with a good ORM is composability, though. Trying to build dynamic SQL queries with raw strings is a nightmare. Another, less useful property, is a considerable reduction of boilerplate when persisting a complex object graph.

pjmlp 12y ago
> Trying to build dynamic SQL queries with raw strings is a nightmare. Create the optimized version in a SQL editor, then use the builder pattern to fill in the holes in the query. Much less boilerplate than any ORM tool generates. > Another, less useful property, is a considerable reduction of boilerplate when persisting a complex object graph. That depends how expressive is the application language's meta-programming capabilities. The thing is, if I have to fine-tune the ORM generated SQL for optimal performance, its value diminishes.
- 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 ago
    Yeah, 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.
joesmo 12y ago
There are plenty of non-ORM database layer solutions for composing SQL queries.
sixbrx 12y ago
I agree that composability is an important concern, which is why I like to use what someone above called an "ARM" (abstract relational model) library, instead of an ORM. I'd put in that category Squeryl (Scala), jooq (Java), and SQLAlchemy (Python), which all allow building relational queries "on their own terms" and allow for easy composition. Another side benefit is it lets the library authors worry about portability between databases so it's much less of an issue.

pjmlp 12y ago

> Trying to build dynamic SQL queries with raw strings is a nightmare. Create the optimized version in a SQL editor, then use the builder pattern to fill in the holes in the query. Much less boilerplate than any ORM tool generates. > Another, less useful property, is a considerable reduction of boilerplate when persisting a complex object graph. That depends how expressive is the application language's meta-programming capabilities. The thing is, if I have to fine-tune the ORM generated SQL for optimal performance, its value diminishes.

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 ago
  Yeah, 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.

joesmo 12y ago

There are plenty of non-ORM database layer solutions for composing SQL queries.

sixbrx 12y ago

I agree that composability is an important concern, which is why I like to use what someone above called an "ARM" (abstract relational model) library, instead of an ORM. I'd put in that category Squeryl (Scala), jooq (Java), and SQLAlchemy (Python), which all allow building relational queries "on their own terms" and allow for easy composition. Another side benefit is it lets the library authors worry about portability between databases so it's much less of an issue.