4 ms·

I get why people hate on ORM's, but let's not throw out the baby with the bathwater here - I don't want to go back to the time where you had to write object def

by roel_v 8y ago

I get why people hate on ORM's, but let's not throw out the baby with the bathwater here - I don't want to go back to the time where you had to write object definitions for each table the database, and manually sync them. Nor do I want to manually write trivial 'select name from foo where id=1' queries all day, and do all the plumbing to execute it. So when hating on ORM's and unnecessary abstraction layers, please qualify that with 'ORM's should not try to be too smart' and 'ORM's should provide fall throughs into whatever they're abstracting for non-trivial use cases', and not give people the idea to ditch ORM's all together.

saas_co_de 8y ago
> const selectBy = (table, column, value) => db.query(`SELECT * FROM :table WHERE :column = :value`, {table, column, value}) > const selectOneBy = (table, column, value) => { const res = selectBy(table, column, value); return res && res.shift() } Two or three lines gives you about 80% of the value in any ORM and avoids the -20% value found in the other 100k LOC.
- idoubtit 8y ago
  > Two or three lines gives you about 80% of the value in any ORM and avoids the -20% value found in the other 100k LOC. I have a hard time believing this when the two lines above are obviously wrong. You can't use :column to escape the name of a column in SQL. So your code has to protect it, which is not easy if you wan't to be portable. MySQL will generally use `column` but may be configured to use the standard "column". Anyway, selectAllBy() and selectOneBy() are not enough to be confortable. I appreciate the static completion in Something.find({id: 1}).complete, the relative queries like Post.find({id: 1}).author, and many other things that help against typos, help code faster and make the code more readable. I agree with the OP that fallthroughs are much needed, because writing custom SQL is sometimes simpler, and sometimes much more performant. Usually, its mostly about writing SomeModel.findAllBySql() which most ActiveRecord implementations provide.
  - saas_co_de 8y ago
    > the two lines above are obviously wrong there is something called psuedo code. use your imagination. > Anyway, selectAllBy() and selectOneBy() are not enough to be confortable Like I said: 80%. > SomeModel.findAllBySql() which most ActiveRecord implementations provide So you are arguing that you should use a huge ORM code base, full of bugs, but then don't use it for anything complex, which means don't use 80% of the code, which is what "handles" all those complex edge cases. Except then you have to have your team agree on what "complex" is, and half the team (who don't actually code anything complex) argue that you should use the ORM for everything, and then you end up in the sh-tshow that most amateur shops that build on ORMs are in. Bottom line, ORMs are for low skill teams that basically don't know what they are doing, and if they ditched the ORM they might actually be able to learn to code decent systems.
    - dang 8y ago
      Please don't cross into incivility when commenting here, regardless of how right you are or feel you are. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- deleted 8y ago
  [deleted]
SOLAR_FIELDS 8y ago
There definitely is a reasonable middle ground. The best ORMs I have dealt with provide straightforward paths for simple queries and then let you drop to raw SQL for complex/performance critical stuff.
- chengiz 8y ago
  "Make simple things simple and complex things possible" - worth putting this placard on every ORM/API/DSL/GUI developer's desk.
  - ccleve 8y ago
    I wrote almost that exact line in my blog post on the topic: "So a better ORM should make the simple things easy, and the hard things possible." https://blog.dieselpoint.com/a-minimalist-good-enough-approach-to-object-relational-mapping-64df9798b276 https://blog.dieselpoint.com/a-minimalist-good-enough-approa...
TeMPOraL 8y ago
> I don't want to go back to the time where you had to write object definitions for each table the database, and manually sync them. Sure. Though I'd love if ORMs would seal autogenerated classes to prevent inheriting from them, language allowing, or otherwise prevent people from using generated ActiveRecord objects as their business model objects. ORMs should be just for creating an OO view into relational storage. They should not be running business logic. I know that people worry about having to write another set of classes just to wrap the ORM ones, but really, sooner or later (usually sooner) your business logic abstractions will stop mapping 1:1 to storage needs, and then you'll be wishing you had that extra layer of separation. Or, in other words, treat ORMs as a more verbose and somewhat-compile-time-checked SQL. Nothing more.
- icebraining 8y ago
  I've had that problem, but frankly it was easier to make an hybrid (mostly ActiveRecord with a few "weird" classes that delegated their own storage) than to write a full Data Mapper layer.
CaptainZapp 8y ago
Nor do I want to manually write trivial 'select name from foo where id=1' You don't have too. SQL is brilliant for writing queries that generate repetitive, standard SQL queries. Provided that the database vendor documents the system tables.
3pt14159 8y ago
Also, ORMs do more than replace a SQL statement. They compose together so when you have code like: person.orders.first And you change your database to make an intermediary table when business needs change and you need multiple people to be associated with an order you don't need to change the above line of code, you just call a class method in person and everything continues to work. It only gets more powerful with scopes and other things. I still drop into SQL, but usually when I'm doing data analysis, not normal business logic.
- SahAssar 8y ago
  Why not make that a view or a stored procedure instead of keeping it as the ORM layer in the application code?
  - Viliam1234 8y ago
    If you use this convenient syntax in many places, replacing it with views could result in hundreds of extra views in the database. Then you would have to maintain them whenever something changes.

by roel_v 8y ago

saas_co_de 8y ago

> const selectBy = (table, column, value) => db.query(`SELECT * FROM :table WHERE :column = :value`, {table, column, value}) > const selectOneBy = (table, column, value) => { const res = selectBy(table, column, value); return res && res.shift() } Two or three lines gives you about 80% of the value in any ORM and avoids the -20% value found in the other 100k LOC.

idoubtit 8y ago
> Two or three lines gives you about 80% of the value in any ORM and avoids the -20% value found in the other 100k LOC. I have a hard time believing this when the two lines above are obviously wrong. You can't use :column to escape the name of a column in SQL. So your code has to protect it, which is not easy if you wan't to be portable. MySQL will generally use `column` but may be configured to use the standard "column". Anyway, selectAllBy() and selectOneBy() are not enough to be confortable. I appreciate the static completion in Something.find({id: 1}).complete, the relative queries like Post.find({id: 1}).author, and many other things that help against typos, help code faster and make the code more readable. I agree with the OP that fallthroughs are much needed, because writing custom SQL is sometimes simpler, and sometimes much more performant. Usually, its mostly about writing SomeModel.findAllBySql() which most ActiveRecord implementations provide.
- saas_co_de 8y ago
  > the two lines above are obviously wrong there is something called psuedo code. use your imagination. > Anyway, selectAllBy() and selectOneBy() are not enough to be confortable Like I said: 80%. > SomeModel.findAllBySql() which most ActiveRecord implementations provide So you are arguing that you should use a huge ORM code base, full of bugs, but then don't use it for anything complex, which means don't use 80% of the code, which is what "handles" all those complex edge cases. Except then you have to have your team agree on what "complex" is, and half the team (who don't actually code anything complex) argue that you should use the ORM for everything, and then you end up in the sh-tshow that most amateur shops that build on ORMs are in. Bottom line, ORMs are for low skill teams that basically don't know what they are doing, and if they ditched the ORM they might actually be able to learn to code decent systems.
  - dang 8y ago
    Please don't cross into incivility when commenting here, regardless of how right you are or feel you are. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
deleted 8y ago
[deleted]

SOLAR_FIELDS 8y ago

There definitely is a reasonable middle ground. The best ORMs I have dealt with provide straightforward paths for simple queries and then let you drop to raw SQL for complex/performance critical stuff.

chengiz 8y ago
"Make simple things simple and complex things possible" - worth putting this placard on every ORM/API/DSL/GUI developer's desk.
- ccleve 8y ago
  I wrote almost that exact line in my blog post on the topic: "So a better ORM should make the simple things easy, and the hard things possible." https://blog.dieselpoint.com/a-minimalist-good-enough-approach-to-object-relational-mapping-64df9798b276 https://blog.dieselpoint.com/a-minimalist-good-enough-approa...

TeMPOraL 8y ago

> I don't want to go back to the time where you had to write object definitions for each table the database, and manually sync them. Sure. Though I'd love if ORMs would seal autogenerated classes to prevent inheriting from them, language allowing, or otherwise prevent people from using generated ActiveRecord objects as their business model objects. ORMs should be just for creating an OO view into relational storage. They should not be running business logic. I know that people worry about having to write another set of classes just to wrap the ORM ones, but really, sooner or later (usually sooner) your business logic abstractions will stop mapping 1:1 to storage needs, and then you'll be wishing you had that extra layer of separation. Or, in other words, treat ORMs as a more verbose and somewhat-compile-time-checked SQL. Nothing more.

icebraining 8y ago
I've had that problem, but frankly it was easier to make an hybrid (mostly ActiveRecord with a few "weird" classes that delegated their own storage) than to write a full Data Mapper layer.

CaptainZapp 8y ago

Nor do I want to manually write trivial 'select name from foo where id=1' You don't have too. SQL is brilliant for writing queries that generate repetitive, standard SQL queries. Provided that the database vendor documents the system tables.

3pt14159 8y ago

Also, ORMs do more than replace a SQL statement. They compose together so when you have code like: person.orders.first And you change your database to make an intermediary table when business needs change and you need multiple people to be associated with an order you don't need to change the above line of code, you just call a class method in person and everything continues to work. It only gets more powerful with scopes and other things. I still drop into SQL, but usually when I'm doing data analysis, not normal business logic.

SahAssar 8y ago
Why not make that a view or a stored procedure instead of keeping it as the ORM layer in the application code?
- Viliam1234 8y ago
  If you use this convenient syntax in many places, replacing it with views could result in hundreds of extra views in the database. Then you would have to maintain them whenever something changes.