3 ms·

I've never really understood this argument. Yes, it's a disadvantage to "have no idea how things work underneath". But why can't you know how things work undern

by murz 15y ago

I've never really understood this argument. Yes, it's a disadvantage to "have no idea how things work underneath". But why can't you know how things work underneath and still use the abstraction layer? You can even log the SQL queries it generates, and drop down to custom SQL queries if necessary. If you're paying attention to what's going on "underneath", what is the problem with using abstractions that remove some boilerplate?

paulhauggis 15y ago
"You can even log the SQL queries it generates, and drop down to custom SQL queries if necessary. If you're paying attention to what's going on "underneath", what is the problem with using abstractions that remove some boilerplate?" In most of the frameworks I've seen, to do so means to hack around the base framework. It's also much faster to just write the correct query in the first place rather than logging every query from the framework and trying to change them for each situation that requires optimization.
- murz 15y ago
  > In most of the frameworks I've seen, to do so means to hack around the base framework. ActiveRecord [1][2] and Django [3][4] both feature logging sql and dropping down to custom sql out of the box, so I'm not sure which frameworks you had to hack around to accomplish that but those are the two examples you used in your OP. > It's also much faster to just write the correct query in the first place rather than logging every query from the framework and trying to change them for each situation that requires optimization. In my experience, 90% or more of the generated queries are fine, there's just a few that need rewriting. And it's not like it takes a lot of cognitive overhead to glance at a console to see what queries are being executed while you're testing that new feature you just added. For me, it's certainly less overhead than writing all of them myself. [1] http://weblog.jamisbuck.org/2007/1/8/watching-activerecord-do-it-s-thing http://weblog.jamisbuck.org/2007/1/8/watching-activerecord-d... [2] http://api.rubyonrails.org/classes/ActiveRecord/Base.html#method-c-find_by_sql http://api.rubyonrails.org/classes/ActiveRecord/Base.html#me... [3] https://docs.djangoproject.com/en/dev/topics/logging/#django-db-backends https://docs.djangoproject.com/en/dev/topics/logging/#django... [4] https://docs.djangoproject.com/en/dev/topics/db/sql/#django.db.models.Manager.raw https://docs.djangoproject.com/en/dev/topics/db/sql/#django....
  - flomo 15y ago
    Well, RoR is living on Mysql defaults turd planet and therefore thinks Foreign Keys are a DRY thing and not a database optimization. So I'm pretty sure anybody with more than a trivial Rails app is manually indexing those columns. Either that or they are spending way more on their database than they should be.
    - einhverfr 15y ago
      I think the fundamental problem is that Rails is based on active hostility towards database engineering. It's the same thing that MySQL did early on. It works very well in some cases but has a serious cost attached that few people want to talk about, namely the fact that things suddenly become problematic when you want to use the RDBMS to effectively share data between diverse applications. The thing is that once you make this tradeoff, I wonder whether it is really that helpful to stick with an RDBMS at all, or whether NoSQL is a better option.
      - dasil003 15y ago
        Good point, however at least ActiveRecord doesn't make the mistake of trying to utterly hide SQL from the user. Since moving to arel in Rails 3.0 things are very clean, logical, and not trying to do to much. It's not particularly hostile to serious SQL developers even if it doesn't have proper language-level tooling for advanced SQL. I think it's still a clear win over NoSQL where a one-size-fits-all solution is simply impossible and would send Rails off into the weeds.
        einhverfr 15y ago
        But you have an inherent tradeoff in ORM-land., You can either essentially build your database as an object store around your ORM or you can build your database and do real SQL coding. But at that point why use an ORM like Active Record at all?
        masklinn 15y ago

by murz 15y ago

paulhauggis 15y ago

"You can even log the SQL queries it generates, and drop down to custom SQL queries if necessary. If you're paying attention to what's going on "underneath", what is the problem with using abstractions that remove some boilerplate?" In most of the frameworks I've seen, to do so means to hack around the base framework. It's also much faster to just write the correct query in the first place rather than logging every query from the framework and trying to change them for each situation that requires optimization.

murz 15y ago
> In most of the frameworks I've seen, to do so means to hack around the base framework. ActiveRecord [1][2] and Django [3][4] both feature logging sql and dropping down to custom sql out of the box, so I'm not sure which frameworks you had to hack around to accomplish that but those are the two examples you used in your OP. > It's also much faster to just write the correct query in the first place rather than logging every query from the framework and trying to change them for each situation that requires optimization. In my experience, 90% or more of the generated queries are fine, there's just a few that need rewriting. And it's not like it takes a lot of cognitive overhead to glance at a console to see what queries are being executed while you're testing that new feature you just added. For me, it's certainly less overhead than writing all of them myself. [1] http://weblog.jamisbuck.org/2007/1/8/watching-activerecord-do-it-s-thing http://weblog.jamisbuck.org/2007/1/8/watching-activerecord-d... [2] http://api.rubyonrails.org/classes/ActiveRecord/Base.html#method-c-find_by_sql http://api.rubyonrails.org/classes/ActiveRecord/Base.html#me... [3] https://docs.djangoproject.com/en/dev/topics/logging/#django-db-backends https://docs.djangoproject.com/en/dev/topics/logging/#django... [4] https://docs.djangoproject.com/en/dev/topics/db/sql/#django.db.models.Manager.raw https://docs.djangoproject.com/en/dev/topics/db/sql/#django....
- flomo 15y ago
  Well, RoR is living on Mysql defaults turd planet and therefore thinks Foreign Keys are a DRY thing and not a database optimization. So I'm pretty sure anybody with more than a trivial Rails app is manually indexing those columns. Either that or they are spending way more on their database than they should be.
  - einhverfr 15y ago
    I think the fundamental problem is that Rails is based on active hostility towards database engineering. It's the same thing that MySQL did early on. It works very well in some cases but has a serious cost attached that few people want to talk about, namely the fact that things suddenly become problematic when you want to use the RDBMS to effectively share data between diverse applications. The thing is that once you make this tradeoff, I wonder whether it is really that helpful to stick with an RDBMS at all, or whether NoSQL is a better option.
    - dasil003 15y ago
      Good point, however at least ActiveRecord doesn't make the mistake of trying to utterly hide SQL from the user. Since moving to arel in Rails 3.0 things are very clean, logical, and not trying to do to much. It's not particularly hostile to serious SQL developers even if it doesn't have proper language-level tooling for advanced SQL. I think it's still a clear win over NoSQL where a one-size-fits-all solution is simply impossible and would send Rails off into the weeds.
      - einhverfr 15y ago
        But you have an inherent tradeoff in ORM-land., You can either essentially build your database as an object store around your ORM or you can build your database and do real SQL coding. But at that point why use an ORM like Active Record at all?
        masklinn 15y ago