4 ms·

On the contrary, having a real data structure that represents the query you want your ORM to execute removes potential bugs! The alternative/old method of gene

by fizx 17y ago

On the contrary, having a real data structure that represents the query you want your ORM to execute removes potential bugs! The alternative/old method of generating SQL was a bunch of kludgy string concatenation.

pvg 17y ago
There's also the old/current method of writing SQL by hand. And you're going to have a hard time convincing me that adding another layer of code to anything usually removes bugs. More code = more bugs. Not always, but just about.
- raganwald 17y ago
  I wonder if that depends on your world view? If you are "thinking in SQL," adding a layer of abstraction forces you to think of SQL and then solve the puzzle of "Which Arel incantation produces the desired result?" Whereas if you find a way to think in algebra, Arel implements the abstraction and removes the problem of "Which SQL incantation produces the desired result?" You're right every abstraction introduces some problems. It's can be a win if the abstraction's mental model is congruent to your thinking or to the problem space.
  - pvg 17y ago
    I think it's it's really more a matter of experience than a worldview. In a previous life, I used to work on a (commercial) product with similar capabilities. I'm also not the sort of database superhero that can just spew optimal SQL effortlessly. In fact, I do tend to think at a level closer to relational algebra. I've just come to find such abstraction layers less useful in the typical web app. They seem to be more applicable in an enterprise app setting where portability is important, control over the schema might be limited or non-existent, the performance and scalability requirements are more predictable. In a web app, the structural complexity of the data is often low or the data is not well-representable in relational form (note the rise in popularity of non-relational stores). Performance requirements are harder to predict. Adding an relational algebra abstraction layer in that context often doesn't add enough value to justify the increase in complexity - you still end up having to understand the entire depth of the stack while getting little benefit from the extra capabilities it offers beyond the warm fuzzy feeling of using something pretty neat.

by fizx 17y ago

pvg 17y ago

There's also the old/current method of writing SQL by hand. And you're going to have a hard time convincing me that adding another layer of code to anything usually removes bugs. More code = more bugs. Not always, but just about.

raganwald 17y ago
I wonder if that depends on your world view? If you are "thinking in SQL," adding a layer of abstraction forces you to think of SQL and then solve the puzzle of "Which Arel incantation produces the desired result?" Whereas if you find a way to think in algebra, Arel implements the abstraction and removes the problem of "Which SQL incantation produces the desired result?" You're right every abstraction introduces some problems. It's can be a win if the abstraction's mental model is congruent to your thinking or to the problem space.
- pvg 17y ago
  I think it's it's really more a matter of experience than a worldview. In a previous life, I used to work on a (commercial) product with similar capabilities. I'm also not the sort of database superhero that can just spew optimal SQL effortlessly. In fact, I do tend to think at a level closer to relational algebra. I've just come to find such abstraction layers less useful in the typical web app. They seem to be more applicable in an enterprise app setting where portability is important, control over the schema might be limited or non-existent, the performance and scalability requirements are more predictable. In a web app, the structural complexity of the data is often low or the data is not well-representable in relational form (note the rise in popularity of non-relational stores). Performance requirements are harder to predict. Adding an relational algebra abstraction layer in that context often doesn't add enough value to justify the increase in complexity - you still end up having to understand the entire depth of the stack while getting little benefit from the extra capabilities it offers beyond the warm fuzzy feeling of using something pretty neat.