7 ms·

The post specifically complains about ActiveRecord, and claims that the abstraction of ORM breaks down not for 20% of projects, but close to 100% of them. This

by ekidd 15y ago

The post specifically complains about ActiveRecord, and claims that the abstraction of ORM breaks down not for 20% of projects, but close to 100% of them. This certainly doesn't match with my experience, and I've worked on dozens of projects using ActiveRecord. Some of these were hairy production projects with strict performance requirements and complicated schemas. About 90% of the time, the ORM does the right thing. It creates, updates and deletes individual records, and it generates entirely reasonable queries. And it does this without requiring dozens or hundreds of lines of SQL. You'll get much better performance out of ActiveRecord if you know a few tricks, however: - Read the SQL queries in development.log to make sure they're sane, and use New Relic to find slow queries in production. - Use 'include' to load a model and its associated objects in 2 queries instead of 1+N queries. - Use 'select' to load only the necessary columns from your tables. - Don't try to force it: If you hit something weird, never hesitate to fall back to SQL. ActiveRecord provides a dozen different places where you can inject small SQL fragments into your queries, or you can just call 'find_by_sql' and do everything by hand. If you start out with basic ORM models, benchmark your database, and add some raw SQL as you scale, you can get reasonable rcesults with ActiveRecord. If it breaks down for 100% of projects, you either have a weird definition of "breaks down", or you're doing it wrong.

zaphar 15y ago
What you just describe is exactly what he defines as breaking down. You may not consider this a big deal but he is right that instead of just learning SQL or an ORM you have to learn/use both. The abstraction does break down somewhere for close to 100% of projects in my own experience, usually for exactly the reasons he is describing. Saying it's no big deal doesn't change the fact that each of the points he makes in his post do indeed happen. Now I'll grant you that this may not personally bug you that much. It bugs me quite a bit though.
- div 15y ago
  If you use a relational database and believe you don't need to know sql, you're delusional. If you are using a relational database, know sql, and want to eliminate a TON of boilerplate, use an ORM. I don't know of many ORM's that claim "Use us and you won't have to know SQL". That's just a straw man argument. If you define breaking down in the terms mentioned by the comment you are replying to, you are playing a semantics game to frame the debate to be: this ORM sucks because I can't use it without knowing sql.
  - zaphar 15y ago
    no. I define it thus. "If I already know SQL why should I have to learn this ORM?" SQL already works and does what I need. What does an orm give me that makes the headache of figuring out when I need to shift to naked SQL worth it? Why try to hide the SQL when its just going to leak out to me in non obvious ways later anyway. That is the authors point as well I think.
    - pardo 15y ago
      As the parent wrote, an ORM allows you to eliminate a TON of boilerplate. Since most ORMs I've worked with are not really as complicated to learn as you try to make it sound, the trade-off is clear. EDIT: fixed a typo.
    - craftsman 15y ago
      I'm really not trying to flame here, so bear with me. :) It's just that in software, the argument "If I already know A, so why should I have to learn B" isn't really useful. Given that software is often about pushing down complexity, one of our main tools is building a "B" so that we don't have to do "A". I know how to write socket code in C, but I'm glad for libraries that don't force me to think about that level--I can pop up a level or two. Examples continue ad infinitum. On the other hand, I can buy the argument "B isn't really very good at abstracting A; I've tried to use B, and every time I use B, I end up just doing A anyway. So B isn't useful." But with ORMs, my experience isn't so black-and-white. I find them very useful a lot of the time. When I run into problems, I can switch to doing SQL directly. That's an okay tradeoff for me. I can certainly understand if others don't find that tradeoff as useful.
      - zaphar 15y ago
        Doesn't look like a flame to me :-) My point was more B doesn't in my experience abstract A well enough to justify its use in anything other than toy or really simple apps that won't live very long or won't have much maintenance. I don't mind an upfront cost if it means I won't be pulling my hair out at 2am trying to make some database call take less then 10 minutes to complete. (Exaggerating there but you get the idea.) If B doesn't do a great job abstracting A then the time spent learning B feels wasted to me. (Edit : extrapolate to abstract)
- stonemetal 15y ago
  There is the problem for me. ORMs (well maybe Entity Framework with LINQ) don't attempt to be an abstraction. They are more like sprintf. Knowing sprintf doesn't free you from knowing what numbers look like as strings. ORMs don't free you from knowing SQL. They free you from having to write some tedious shelping rows to objects.
code_duck 15y ago
"Don't try to force it: If you hit something weird, never hesitate to fall back to SQL. ActiveRecord provides a dozen different places where you can inject small SQL fragments into your queries, or you can just call 'find_by_sql' and do everything by hand." I'm comfortable working like that, but it is exactly what the article is criticizing. Sure, it works - but the whole idea of an ORM was supposed to be avoding that.
- Sapient 15y ago
  I believe ORMs want to save you from writing tons of repetitive queries, not to save you from ever having to touch a line of SQL. At least that is what I believe, I have never seen an ORM advertising itself with "NEVER WRITE ANOTHER LINE OF SQL AGAIN".
  - deleted 15y ago
    [deleted]
- jimktrains2 15y ago
  No, the idea behind an ORM is to make the common case easy and safe.
- davesims 15y ago
  "But the whole idea of an ORM was supposed to be avoding that." Maybe some ORM zealots said that in the past, but that certainly isn't the common conception now. ORMs as they're actually used properly today allow devs who know SQL really well to eliminate code dup. If you can't drop into SQL quickly, stay away from ORMs, you're going to hurt yourself and others.
5l 15y ago
Although he did specifically call out Ruby on Rails I rather think he meant ActiveRecord the pattern [0] rather than ActiveRecord the implementation [1]. Ruby on Rails' ActiveRecord has come a long way and actually implements proper relational algebra through Arel [2] now. [0] http://martinfowler.com/eaaCatalog/activeRecord.html http://martinfowler.com/eaaCatalog/activeRecord.html [1] http://ar.rubyonrails.org/classes/ActiveRecord/Base.html http://ar.rubyonrails.org/classes/ActiveRecord/Base.html [2] https://github.com/nkallen/arel https://github.com/nkallen/arel
Xurinos 15y ago
The alternative and more flexible approach is to use a software package with the Data Mapper pattern. It differs in that one is no longer tightly coupled to the actual database tables. Instead, you can create whatever views of the data make sense to your application. Even though it seems like a higher level of abstraction, you actually have greater access to all the features SQL provides, almost in the form of an SQL builder. One example of the Data Mapper pattern is in python's SQLAlchemy. Another is in perl's DBIx::ObjectMapper.

by ekidd 15y ago

zaphar 15y ago

What you just describe is exactly what he defines as breaking down. You may not consider this a big deal but he is right that instead of just learning SQL or an ORM you have to learn/use both. The abstraction does break down somewhere for close to 100% of projects in my own experience, usually for exactly the reasons he is describing. Saying it's no big deal doesn't change the fact that each of the points he makes in his post do indeed happen. Now I'll grant you that this may not personally bug you that much. It bugs me quite a bit though.

div 15y ago
If you use a relational database and believe you don't need to know sql, you're delusional. If you are using a relational database, know sql, and want to eliminate a TON of boilerplate, use an ORM. I don't know of many ORM's that claim "Use us and you won't have to know SQL". That's just a straw man argument. If you define breaking down in the terms mentioned by the comment you are replying to, you are playing a semantics game to frame the debate to be: this ORM sucks because I can't use it without knowing sql.
- zaphar 15y ago
  no. I define it thus. "If I already know SQL why should I have to learn this ORM?" SQL already works and does what I need. What does an orm give me that makes the headache of figuring out when I need to shift to naked SQL worth it? Why try to hide the SQL when its just going to leak out to me in non obvious ways later anyway. That is the authors point as well I think.
  - pardo 15y ago
    As the parent wrote, an ORM allows you to eliminate a TON of boilerplate. Since most ORMs I've worked with are not really as complicated to learn as you try to make it sound, the trade-off is clear. EDIT: fixed a typo.
  - craftsman 15y ago
    I'm really not trying to flame here, so bear with me. :) It's just that in software, the argument "If I already know A, so why should I have to learn B" isn't really useful. Given that software is often about pushing down complexity, one of our main tools is building a "B" so that we don't have to do "A". I know how to write socket code in C, but I'm glad for libraries that don't force me to think about that level--I can pop up a level or two. Examples continue ad infinitum. On the other hand, I can buy the argument "B isn't really very good at abstracting A; I've tried to use B, and every time I use B, I end up just doing A anyway. So B isn't useful." But with ORMs, my experience isn't so black-and-white. I find them very useful a lot of the time. When I run into problems, I can switch to doing SQL directly. That's an okay tradeoff for me. I can certainly understand if others don't find that tradeoff as useful.
    - zaphar 15y ago
      Doesn't look like a flame to me :-) My point was more B doesn't in my experience abstract A well enough to justify its use in anything other than toy or really simple apps that won't live very long or won't have much maintenance. I don't mind an upfront cost if it means I won't be pulling my hair out at 2am trying to make some database call take less then 10 minutes to complete. (Exaggerating there but you get the idea.) If B doesn't do a great job abstracting A then the time spent learning B feels wasted to me. (Edit : extrapolate to abstract)
stonemetal 15y ago
There is the problem for me. ORMs (well maybe Entity Framework with LINQ) don't attempt to be an abstraction. They are more like sprintf. Knowing sprintf doesn't free you from knowing what numbers look like as strings. ORMs don't free you from knowing SQL. They free you from having to write some tedious shelping rows to objects.

code_duck 15y ago

"Don't try to force it: If you hit something weird, never hesitate to fall back to SQL. ActiveRecord provides a dozen different places where you can inject small SQL fragments into your queries, or you can just call 'find_by_sql' and do everything by hand." I'm comfortable working like that, but it is exactly what the article is criticizing. Sure, it works - but the whole idea of an ORM was supposed to be avoding that.

Sapient 15y ago
I believe ORMs want to save you from writing tons of repetitive queries, not to save you from ever having to touch a line of SQL. At least that is what I believe, I have never seen an ORM advertising itself with "NEVER WRITE ANOTHER LINE OF SQL AGAIN".
- deleted 15y ago
  [deleted]
jimktrains2 15y ago
No, the idea behind an ORM is to make the common case easy and safe.
davesims 15y ago
"But the whole idea of an ORM was supposed to be avoding that." Maybe some ORM zealots said that in the past, but that certainly isn't the common conception now. ORMs as they're actually used properly today allow devs who know SQL really well to eliminate code dup. If you can't drop into SQL quickly, stay away from ORMs, you're going to hurt yourself and others.

5l 15y ago

Although he did specifically call out Ruby on Rails I rather think he meant ActiveRecord the pattern [0] rather than ActiveRecord the implementation [1]. Ruby on Rails' ActiveRecord has come a long way and actually implements proper relational algebra through Arel [2] now. [0] http://martinfowler.com/eaaCatalog/activeRecord.html http://martinfowler.com/eaaCatalog/activeRecord.html [1] http://ar.rubyonrails.org/classes/ActiveRecord/Base.html http://ar.rubyonrails.org/classes/ActiveRecord/Base.html [2] https://github.com/nkallen/arel https://github.com/nkallen/arel

Xurinos 15y ago

The alternative and more flexible approach is to use a software package with the Data Mapper pattern. It differs in that one is no longer tightly coupled to the actual database tables. Instead, you can create whatever views of the data make sense to your application. Even though it seems like a higher level of abstraction, you actually have greater access to all the features SQL provides, almost in the form of an SQL builder. One example of the Data Mapper pattern is in python's SQLAlchemy. Another is in perl's DBIx::ObjectMapper.