3 ms·

Do you feel that way about all ORMs or just ActiveRecord? How would you like it to be different?

cwyers 10y ago
From what I've seen of it, LINQ to SQL (or other ORMs hooking up to LINQ on the .NET ecosystem, like Entity Framework) can avoid the feel of what Jacques is talking about. LINQ lets you express queries in C# (or what have you) syntax but still exposes the "feel" of an SQL database, not just using the database as a persistent object store.
- nol13 10y ago
  New project is using node/sequelize, and ya, I miss LINQ.
jacques_chester 10y ago
No ORM ever hits a universally happy solution; graphs and sets are equally powerful but express the world in fundamentally different ways. ActiveRecord is particularly annoying because it is bad both to the database and the programmer. To the database it is bad by making a great show of holding its nose while dealing with the lowly bit box, making scrupulously sure to avoid taking advantage of the fact that the database has locality and enforceability. I've encountered true production race conditions that Rails validations can't solve. It is a professional embarrassment when clients receive duplicate emails about the multi-umptillion dollar software we've sold them. Meanwhile, a single constraint in Postgres prevents it from ever happening again. And it's bad to the programmer by exposing a massive interface that you are meant to inherit from for construction. Ironically it's named after the Active Record pattern which is about making a thin interface with a table, which you can then build your own business-specific domain translation layer. But in Rails that's not really how it works. I used to think the mismatch could be solved by lurching towards sets[1]. But I don't think it would be a very easy transition and more to the point, I don't have anything strong to back up my argument that a collection of grumpiness about the ways various ORMs obscure the power of relational modelling. [1] http://chester.id.au/2013/08/28/notes-towards-a-set-objective-language/ http://chester.id.au/2013/08/28/notes-towards-a-set-objectiv...

From what I've seen of it, LINQ to SQL (or other ORMs hooking up to LINQ on the .NET ecosystem, like Entity Framework) can avoid the feel of what Jacques is talking about. LINQ lets you express queries in C# (or what have you) syntax but still exposes the "feel" of an SQL database, not just using the database as a persistent object store.

nol13 10y ago
New project is using node/sequelize, and ya, I miss LINQ.

jacques_chester 10y ago

No ORM ever hits a universally happy solution; graphs and sets are equally powerful but express the world in fundamentally different ways. ActiveRecord is particularly annoying because it is bad both to the database and the programmer. To the database it is bad by making a great show of holding its nose while dealing with the lowly bit box, making scrupulously sure to avoid taking advantage of the fact that the database has locality and enforceability. I've encountered true production race conditions that Rails validations can't solve. It is a professional embarrassment when clients receive duplicate emails about the multi-umptillion dollar software we've sold them. Meanwhile, a single constraint in Postgres prevents it from ever happening again. And it's bad to the programmer by exposing a massive interface that you are meant to inherit from for construction. Ironically it's named after the Active Record pattern which is about making a thin interface with a table, which you can then build your own business-specific domain translation layer. But in Rails that's not really how it works. I used to think the mismatch could be solved by lurching towards sets[1]. But I don't think it would be a very easy transition and more to the point, I don't have anything strong to back up my argument that a collection of grumpiness about the ways various ORMs obscure the power of relational modelling. [1] http://chester.id.au/2013/08/28/notes-towards-a-set-objective-language/ http://chester.id.au/2013/08/28/notes-towards-a-set-objectiv...