5 ms·

I don't know that a better ORM than ActiveRecord is imaginable. It's seriously good, and getting better every year. I don't think a better DSL for database wran

I don't know that a better ORM than ActiveRecord is imaginable. It's seriously good, and getting better every year. I don't think a better DSL for database wrangling exists, and dropping down to SQL or the intermediate representation (arel) couldn't be easier, you can take any ActiveRelation object and call .to_sql on it to see what it's doing. I've used DataMapper and Sequel, and read through the ROM docs, I don't think any of them really bring something better to the table than good, old, solid Active Record. Linq is expressive and fun, compared to .NET. Nothing compared to Ruby. As abstraction layers go, I can't ask for a better one.

Ygg2 8y ago
> I don't know that a better ORM than ActiveRecord is imaginable. SQL Alchemy https://www.sqlalchemy.org/ https://www.sqlalchemy.org/
- vinceguidry 8y ago
  That's a fair suggestion, as I don't use Python. My feeling is that it would be the same as Linq, really amazing compared to the other Python alternatives, but ultimately hampered by Python when you're trying to compare it across languages / stacks. My distaste for Python runs somewhat deep, I certainly wouldn't involve myself on any web project that uses it. Maybe for games.
  - blattimwind 8y ago
    sqlalchemy is hands-down the best ORM I've ever seen. It only gives you exactly as much magic as you want (imho an annoying problem with anything related to Django) and instead of generating SQL more or less directly it operates on an SQL DSL, which can be extended at just the right points to use pretty much any DB feature, including those sqlalchemy does not know or understand. I don't know Linq personally but I know people liking it very much -- your comparison is probably accurate.
TimTheTinker 8y ago
.NET’s entity framework (combined with Linq in C#) is pretty amazing — if it’s not better than ActiveRecord, it’s at least a strong contender.
- tarr11 8y ago
  When I last used it (maybe 5 years ago), Entity Framework would generate positively awful, bloated SQL queries for complex nested includes. Maybe that's improved now? ActiveRecord always did the right thing, and whenever I looked at the generated SQL I was pleased.
  - nightski 8y ago
    It generally does that if you tell it to. Meaning, you can't completely ignore the fact that the linq query you are writing will be translated into SQL and the closer your linq query looks to the target SQL you are trying to generate the better EF will do (and it does a great job for a wide range of queries from simple to complex in the systems I have worked on).
WJW 8y ago
I agree, ActiveRecord is pretty good. My main gripe with it is that bulk inserts are _still_ not a first class operation, which can easily lead to some horrendous N+1 queries if you are not careful. There are multiple great gems to retrofit that though. It is also a bit overzealous in being database agnostic. For example, MySQL allows for LIMIT clauses on UPDATE and DELETE statements, which is super useful for making sure you don't accidentally create super long running transactions because there were many more rows on the other side of that relation than you expected. However, if you want to use that from ActiveRecord you need to drop down to custom SQL, because not all databases support that SQL pattern.
netghost 8y ago
ActiveRecord is really good, but Sequel[1] is much more flexible. I think it starts from a better base, where as ActiveRecord wraps and mostly hides arel. That said, they're both enormously productive. 1: https://github.com/jeremyevans/sequel https://github.com/jeremyevans/sequel
- vinceguidry 8y ago
  I've used both somewhat extensively, and while I would have agreed with you a few years ago, nowadays I see my earlier ardor for Sequel as mostly just youthful exuberance. Recently I went looking for a schema generation tool, found one that went and looked at an existing database, and generated scaffolding commands to create models and if necessary, controllers and basic CRUD. Only thing it didn't do was has_many associations, of course you could just add those in before running the generated commands. You just can't find this level of refinement anywhere else except maybe Java, of course then you'd have to use Java.
toasterlovin 8y ago
And, in my experience, an ActiveRecord model backed by a database view will solve pretty much every problem you run into where ActiveRecord alone just doesn't cut it.
mping 8y ago
One thing I don't like in the rails/ar mindset is that they hide behind ruby. Example, some ruby methods are provided by active record (projections) but others may not (.pluck). I prefer my queries predictable. Of course if you are a rails senior you already know all the gotchas and can be efficient.
YorickPeterse 8y ago
I have always found ActiveRecord to be extremely limiting, and Sequel to be much better. Some random limitations I have had to deal with over the years (in no particular order): * No support for "OR" statements, without dropping down to raw SQL (I think this was added in either Rails 4, or Rails 5) * Terrible support (if any) for more advanced PostgreSQL features, such as CTEs, bigserial (Rails 5 finally supports this if I'm not mistaken), no proper support for composite primary keys, no support for PostgreSQL CHECK constraints, no support for index expressions (e.g. an index on `lower(foo)`), etc. For GitLab we had to add many hacks to work around this. * A rather messy model API, where models are used as both repositories and objects representing single rows. Sequel makes the same mistake with its ORM, but at least you can use the query toolkit separately. ROM supposedly does this better, but I have not tried it. * Too many methods are injected into your classes, and you'll probably never use most of these (this is a more philosophical issue, and certainly not a deal breaker). There are plenty more, but these are the ones that come to mind. My biggest issue in recent times was caused by ActiveRecord/Arel silently throwing away CTEs used in UPDATEs. Basically in GitLab we did something like this (I don't fully remember what the query was): WITH foo AS ( ... ) UPDATE some_table SET a = b WHERE x = foo.y In other words: we'd grab some data using a (recursive) CTE, then update a bunch of rows based on that data. Unfortunately, ActiveRecord/Arel would throw away the CTE in certain cases. This would result in us effectively running the following: UPDATE some_table SET a = b You can imagine the fun of having to deal with all rows being updated unexpectedly. More details on this particular bug can be found here: https://gitlab.com/gitlab-org/gitlab-ce/issues/37916 https://gitlab.com/gitlab-org/gitlab-ce/issues/37916 Long story short, I'm fairly convinced that using Sequel would have made GitLab's database code much more solid/less buggy than it is today, simply because it supports so much more (and better) out of the box.
StaticRedux 8y ago
While I agree that ActiveRecord is really good in a lot of ways, the entire ecosystem around it is a giant clusterf* waiting to happen, and it always does. Fat models, callbacks, concerns, scopes... changing a model reliably without 100% test coverage is damn near impossible for any relatively complex application and knowing what your model is going to do on any given call is a nightmare when you have a dozen+ callbacks/concerns/scopes/whatever. That 'oh crap I need to deploy a big change, is it going to work right?' feeling never, ever goes away. I've used both ActiveRecord and Entity Framework extensively. And while Entity Framework definitely has it's drawbacks, it doesn't get any better than Linq in combination with static compilation for a large and complex code base with a lot of moving parts. And yes, "don't do that" is all well and good when it comes to the 'right' way to do things in Rails/ActiveRecord, but when DHH himself is driving the callback train at full speed and you take a project over from someone who jumped on the bandwagon and didn't actually know how to properly apply these tools to the code, it's going to be a pretty nasty wreck. You can be damn sure I'd rather take over and refactor a large, messy C#/Linq/Entity Framework project than a large, messy Rails/ActiveRecord project. Also I could never get over the fact that Rails developers for some reason treat foreign keys like it's ebola. "It's just not the Rails way" is not a good answer for not using foreign keys.

Ygg2 8y ago

> I don't know that a better ORM than ActiveRecord is imaginable. SQL Alchemy https://www.sqlalchemy.org/ https://www.sqlalchemy.org/

vinceguidry 8y ago
That's a fair suggestion, as I don't use Python. My feeling is that it would be the same as Linq, really amazing compared to the other Python alternatives, but ultimately hampered by Python when you're trying to compare it across languages / stacks. My distaste for Python runs somewhat deep, I certainly wouldn't involve myself on any web project that uses it. Maybe for games.
- blattimwind 8y ago
  sqlalchemy is hands-down the best ORM I've ever seen. It only gives you exactly as much magic as you want (imho an annoying problem with anything related to Django) and instead of generating SQL more or less directly it operates on an SQL DSL, which can be extended at just the right points to use pretty much any DB feature, including those sqlalchemy does not know or understand. I don't know Linq personally but I know people liking it very much -- your comparison is probably accurate.

TimTheTinker 8y ago

.NET’s entity framework (combined with Linq in C#) is pretty amazing — if it’s not better than ActiveRecord, it’s at least a strong contender.

tarr11 8y ago
When I last used it (maybe 5 years ago), Entity Framework would generate positively awful, bloated SQL queries for complex nested includes. Maybe that's improved now? ActiveRecord always did the right thing, and whenever I looked at the generated SQL I was pleased.
- nightski 8y ago
  It generally does that if you tell it to. Meaning, you can't completely ignore the fact that the linq query you are writing will be translated into SQL and the closer your linq query looks to the target SQL you are trying to generate the better EF will do (and it does a great job for a wide range of queries from simple to complex in the systems I have worked on).

WJW 8y ago

I agree, ActiveRecord is pretty good. My main gripe with it is that bulk inserts are _still_ not a first class operation, which can easily lead to some horrendous N+1 queries if you are not careful. There are multiple great gems to retrofit that though. It is also a bit overzealous in being database agnostic. For example, MySQL allows for LIMIT clauses on UPDATE and DELETE statements, which is super useful for making sure you don't accidentally create super long running transactions because there were many more rows on the other side of that relation than you expected. However, if you want to use that from ActiveRecord you need to drop down to custom SQL, because not all databases support that SQL pattern.

netghost 8y ago

ActiveRecord is really good, but Sequel[1] is much more flexible. I think it starts from a better base, where as ActiveRecord wraps and mostly hides arel. That said, they're both enormously productive. 1: https://github.com/jeremyevans/sequel https://github.com/jeremyevans/sequel

vinceguidry 8y ago
I've used both somewhat extensively, and while I would have agreed with you a few years ago, nowadays I see my earlier ardor for Sequel as mostly just youthful exuberance. Recently I went looking for a schema generation tool, found one that went and looked at an existing database, and generated scaffolding commands to create models and if necessary, controllers and basic CRUD. Only thing it didn't do was has_many associations, of course you could just add those in before running the generated commands. You just can't find this level of refinement anywhere else except maybe Java, of course then you'd have to use Java.

toasterlovin 8y ago

And, in my experience, an ActiveRecord model backed by a database view will solve pretty much every problem you run into where ActiveRecord alone just doesn't cut it.

mping 8y ago

One thing I don't like in the rails/ar mindset is that they hide behind ruby. Example, some ruby methods are provided by active record (projections) but others may not (.pluck). I prefer my queries predictable. Of course if you are a rails senior you already know all the gotchas and can be efficient.

YorickPeterse 8y ago

I have always found ActiveRecord to be extremely limiting, and Sequel to be much better. Some random limitations I have had to deal with over the years (in no particular order): * No support for "OR" statements, without dropping down to raw SQL (I think this was added in either Rails 4, or Rails 5) * Terrible support (if any) for more advanced PostgreSQL features, such as CTEs, bigserial (Rails 5 finally supports this if I'm not mistaken), no proper support for composite primary keys, no support for PostgreSQL CHECK constraints, no support for index expressions (e.g. an index on `lower(foo)`), etc. For GitLab we had to add many hacks to work around this. * A rather messy model API, where models are used as both repositories and objects representing single rows. Sequel makes the same mistake with its ORM, but at least you can use the query toolkit separately. ROM supposedly does this better, but I have not tried it. * Too many methods are injected into your classes, and you'll probably never use most of these (this is a more philosophical issue, and certainly not a deal breaker). There are plenty more, but these are the ones that come to mind. My biggest issue in recent times was caused by ActiveRecord/Arel silently throwing away CTEs used in UPDATEs. Basically in GitLab we did something like this (I don't fully remember what the query was): WITH foo AS ( ... ) UPDATE some_table SET a = b WHERE x = foo.y In other words: we'd grab some data using a (recursive) CTE, then update a bunch of rows based on that data. Unfortunately, ActiveRecord/Arel would throw away the CTE in certain cases. This would result in us effectively running the following: UPDATE some_table SET a = b You can imagine the fun of having to deal with all rows being updated unexpectedly. More details on this particular bug can be found here: https://gitlab.com/gitlab-org/gitlab-ce/issues/37916 https://gitlab.com/gitlab-org/gitlab-ce/issues/37916 Long story short, I'm fairly convinced that using Sequel would have made GitLab's database code much more solid/less buggy than it is today, simply because it supports so much more (and better) out of the box.

StaticRedux 8y ago

While I agree that ActiveRecord is really good in a lot of ways, the entire ecosystem around it is a giant clusterf* waiting to happen, and it always does. Fat models, callbacks, concerns, scopes... changing a model reliably without 100% test coverage is damn near impossible for any relatively complex application and knowing what your model is going to do on any given call is a nightmare when you have a dozen+ callbacks/concerns/scopes/whatever. That 'oh crap I need to deploy a big change, is it going to work right?' feeling never, ever goes away. I've used both ActiveRecord and Entity Framework extensively. And while Entity Framework definitely has it's drawbacks, it doesn't get any better than Linq in combination with static compilation for a large and complex code base with a lot of moving parts. And yes, "don't do that" is all well and good when it comes to the 'right' way to do things in Rails/ActiveRecord, but when DHH himself is driving the callback train at full speed and you take a project over from someone who jumped on the bandwagon and didn't actually know how to properly apply these tools to the code, it's going to be a pretty nasty wreck. You can be damn sure I'd rather take over and refactor a large, messy C#/Linq/Entity Framework project than a large, messy Rails/ActiveRecord project. Also I could never get over the fact that Rails developers for some reason treat foreign keys like it's ebola. "It's just not the Rails way" is not a good answer for not using foreign keys.