4 ms·

Activereord certainly saves me a lot of time. I think the reason orms get a lot of flak is that people see them usedin wildly inefficient ways that could have

by geebee 10y ago

Activereord certainly saves me a lot of time. I think the reason orms get a lot of flak is that people see them usedin wildly inefficient ways that could have been solved with a simple join or other basic sql operation. Or alternatively people to to comical levels of twister to stay within the framework and create a parallel implementation of Sal. But yeah if you use them judiciously they can remove some drudgery.

crdoconnor 10y ago
If your ORM can't handle joins you're just using a bad ORM, period. Pick a better one.
- geebee 10y ago
  I can't think of an orm that can't handle joins. I can think of way that relatively inexperienced devs might use an orm in a day that doesn't take proper advantage of it though (seen it). I don't see this as a reason to avoid an orm of course. In rails it's pretty trivial to load associations most of the time. There are also some queries that I think are best handled by find by sql oreven just raw sql. Sometimes this is performance othertimes it's for clarity. Overall if you use an form properly I think it can save time and improve clarity.
- ryanbrunner 10y ago
  Any ORM can handle joins. There are certain types of joins / aggregations / whatever that are harder for ORMs to support, and thinking that this is the fault of the ORM births monstrosities like Hibernate. ActiveRecord for me hits a sweet spot in that it covers most of what you would need to do day-to-day in SQL and gives you easy ways to bypass it if you need to do something more complicated. The biggest issue with ActiveRecord IMO is Rails devs who feel that falling down to raw SQL when it's warranted is wrong, and end up building insanely unreadable garbage using ARel (which in and of itself isn't a bad library, but should almost never be used in "high-level" code.)
pbowyer 10y ago
I feel the problem is people go to extremes: either all handmade SQL or all ORM. Mixing both is pragmatic. Take today's example, using the Doctrine2 ORM. I needed something simple: For every user, find the number of articles belonging to them with a specific status code. Seems simple. Except the dumb ORM way of count($user->articles) lost the JOIN conditions, and counted every article. So the 50% way was to use COUNT(article.id) in the query via the ORM. Unfortunately, because it doesn't know where to put the COUNT() value, the ORM destroys the easy usage, and returns a collection of the user object and a scalar value for the COUNT(). I worked with it, but TBH going back to raw SQL in this case would've been much easier. Pragmatism, the lost art (TM)

by geebee 10y ago

crdoconnor 10y ago

If your ORM can't handle joins you're just using a bad ORM, period. Pick a better one.

geebee 10y ago
I can't think of an orm that can't handle joins. I can think of way that relatively inexperienced devs might use an orm in a day that doesn't take proper advantage of it though (seen it). I don't see this as a reason to avoid an orm of course. In rails it's pretty trivial to load associations most of the time. There are also some queries that I think are best handled by find by sql oreven just raw sql. Sometimes this is performance othertimes it's for clarity. Overall if you use an form properly I think it can save time and improve clarity.
ryanbrunner 10y ago
Any ORM can handle joins. There are certain types of joins / aggregations / whatever that are harder for ORMs to support, and thinking that this is the fault of the ORM births monstrosities like Hibernate. ActiveRecord for me hits a sweet spot in that it covers most of what you would need to do day-to-day in SQL and gives you easy ways to bypass it if you need to do something more complicated. The biggest issue with ActiveRecord IMO is Rails devs who feel that falling down to raw SQL when it's warranted is wrong, and end up building insanely unreadable garbage using ARel (which in and of itself isn't a bad library, but should almost never be used in "high-level" code.)

pbowyer 10y ago

I feel the problem is people go to extremes: either all handmade SQL or all ORM. Mixing both is pragmatic. Take today's example, using the Doctrine2 ORM. I needed something simple: For every user, find the number of articles belonging to them with a specific status code. Seems simple. Except the dumb ORM way of count($user->articles) lost the JOIN conditions, and counted every article. So the 50% way was to use COUNT(article.id) in the query via the ORM. Unfortunately, because it doesn't know where to put the COUNT() value, the ORM destroys the easy usage, and returns a collection of the user object and a scalar value for the COUNT(). I worked with it, but TBH going back to raw SQL in this case would've been much easier. Pragmatism, the lost art (TM)