6 ms·

[flagged]

thimabi 2y ago
I concur. I’ve used ORMs in certain projects, but iterating and optimizing them later on became untenable. I’ve learned my lesson — all my new projects forgo ORMs by default.
- Daishiman 2y ago
  How? ORM logic is as simple or as complicated as the underlying queries and results. In 15 years of building web apps with Python ORMs this has never been a problem across many, many different teams.
_hcuq 2y ago
Yep, plus learn SQL and you can use it everywhere. Every language has it's own (multiple) language specific ORMs.
bb88 2y ago
And yet, the Vietnam of Computer Science paper didn't stop the creation of ORM's. There's something fundamentally broken with SQL syntax, and yelling at people to "Just Use SQL" doesn't really help.
- mbrumlow 2y ago
  Its better than sitting silent and doing nothing. What it does is validate other peoples feelings who feel the same way. And just maybe, that validation will lead to them saying "fuck ORMs" when some junior dev comes in and tries to use one.
  - bb88 2y ago
    Fair, but it also reinforces the stereotype that the pro-SQL types are obstinate relics yelling at the youngsters to "Get off my lawn!" There's a pattern of "We can't change X, so we'll write Y that transpiles down to X". It happens often with closed source tools and others that can't or won't implement new languages. Verilog, SQL, Javascript, all fit that bill. E.g. Why is Javascript the only first class language for the browser? For the longest time JS was the only game in town.
- sivakon 2y ago
  excuse me, what is Vietnam of Computer Science paper? what’s vietnam has to do with it?
  - steveklabnik 2y ago
    I am not anti-ORM, but I do know that reference: https://www.odbms.org/wp-content/uploads/2013/11/031.01-Neward-The-Vietnam-of-Computer-Science-June-2006.pdf https://www.odbms.org/wp-content/uploads/2013/11/031.01-Newa...
- throwaway19972 2y ago
  > There's something fundamentally broken with SQL syntax ? Are you referring to something specific?
carllerche 2y ago
I respect that some prefer just to use SQL, but that isn't where most stand. Also, instead of a reactionary "all ORMs are trash," where ORM probably means different things to different people, maybe you could provide some value to the conversation by providing specific points and/or arguments supporting your feelings about ORMs. At the very least, you could provide some citation to an article that does the summarization.
alain_gilbert 2y ago
I never understood why people are so stubborn about hating on orm. For example I'm familiar with https://gorm.io https://gorm.io and it does save me a lot of time and useless boilerplate. And guess what, if I ever need to make a complex query, I also happen to know SQL, and I'm just going to make a "raw" query https://gorm.io/docs/sql_builder.html#Raw-SQL https://gorm.io/docs/sql_builder.html#Raw-SQL and be done with it. It's not all that hard. edit: the other common complaint usually is: "but I don't know what query the orm is going to make..." Use "Debug" https://gorm.io/docs/session.html#Debug https://gorm.io/docs/session.html#Debug and it will print out exactly what query it's making. Not happy with it? Make a raw query.
- throwaway19972 2y ago
  > I never understood why people are so stubborn about hating on orm. Objects are just bad abstractions for representing database interactions. They never map cleanly and any attempt to cover up the incoherence introduces further problems. Avoiding boilerplate is understandable, but typed schemas and queries exist without hauling in a full ORM. Of course you can pump out a lot of SQL very quickly with ORMs. There's a lot positive to say about this approach! But you don't tend to end up with code where you can easily tell what's going on.
  - Daishiman 2y ago
    > Objects are just bad abstractions for representing database interactions. But they're excellent abstractions for business entities. > Of course you can pump out a lot of SQL very quickly with ORMs. There's a lot positive to say about this approach! But you don't tend to end up with code where you can easily tell what's going on. 15 years building up massive apps with Django and SQLAlchemy and this has never been a problem.
    - throwaway19972 2y ago
      > 15 years building up massive apps with Django and SQLAlchemy and this has never been a problem. I guarantee you it is if the reader isn't already intimately familiar with SQLAlchemy.
jasfi 2y ago
Moving fast is often crucial, but you typically also get more readable code, which is also worth it. A query/DML that is badly optimized is usually very complex, which means that the ORM's syntax isn't a good fit. No problem, since they typically support raw SQL calls, so nothing is really lost. You just have to know when to use the right tool for the job, as always.
- throwaway19972 2y ago
  > Moving fast is often crucial, but you typically also get more readable code, which is also worth it. I think the exact opposite is true, actually—because of the introduction of stuff like lifecycle hooks it becomes very difficult to figure out how the domain semantics translate to query/execution semantics. Of course some are lighter than that and just e.g. map a table to a domain type (which is much more readable), but that's not typically what catches criticism.
whazor 2y ago
A lot of people think SQL is antiquated, and therefore not worth learning. However, SQL is based upon Relation Algebra, which is the foundation of database optimalisation. Any data querying language/library that is not based on relational algebra will lack the performance. In particular ORMs fall under this category. Having said that, there are other languages/libraries out there that do use the relational algebra constructs.
- 0x457 2y ago
  You still need to know SQL when you're using ORM. You also need to know ORM when you're using one. It's really not that hard to make ORM perform well if you spend some time RTFMing. When was the last time your RDBMS was handling business logic and wasn't just a persistence layer for your application? SQL (the language) isn't composable so you often have a choice of building strings or having many slightly different queries. Anyway, pros of using an ORM outweight it cons in my opinion.
frankjr 2y ago
Nonsense. People use ORMs because the vast majority of queries are trivial. If you need something the ORM doesn't provide sufficient control over, only then you move to raw queries for these cases.
- mbrumlow 2y ago
  It’s has nothing to do with being simple and everything to do with wha the database looks like at the end of the day. Some ORMs are better than others but if if you have ever looked at a database created by a ORM it always has weird lookup tables, funny names and even with simple objects completely unusable without the ORM. We live in a multi language world. There is a high chance you are going to want to access this data with a different language. This langue is not going to have the same ORM as such you will have a horrid time access the data. ORMs often lay their data out in a way that is highly language dependent. The fact of the matter is SQL is not hard and bypassing the main interface to the database and hand wave it away will always bring you regret when writing any sooty of software other than a toy project. Your best case is you become an expert in the ORM. Resulting in a skill set that does not transfer easy, language locked and the worst of all bottle necks any changes to the data layer to your ORM expert who at first will be proud and happy and end smug and bitchy as all the data layers request changes will simply be redirected to them. When people like me say ORMs are trash it’s much more than any of the surface level rebuttals listed here. It’s about the whole life cycle is your project. Adding up all the places ORMs can fuck you just makes it a bad proposition. God forbid you need to upgrade your database or the ORM version.
  - imtringued 2y ago
    Well, different people, different experiences.
    - mbrumlow 2y ago
      Same experience just different time lines.
  - alain_gilbert 2y ago
rwaksmunski 2y ago
Yeah, let's trash the 50 year old industry standard and let's obfuscate the interface to one of the most performance sensitive part of an application. Hell, lets build multiple obfuscators for each language, each with it's own astonishing behavior that turns pathological once you actually get usage on the app.
- 7bit 2y ago
  You know whats also a 50 year old industry Standard? Assembler. Yet, Nobody writes it any more.
imtringued 2y ago
Sorry but anyone who needs to build queries dynamically e.g. for extended/advanced search or ACL is going to significantly benefit from being able to seamlessly mix regular code and query logic. Compare that to the old way of concatenating SQL fragments. Shudder.

[flagged]

I concur. I’ve used ORMs in certain projects, but iterating and optimizing them later on became untenable. I’ve learned my lesson — all my new projects forgo ORMs by default.

Daishiman 2y ago
How? ORM logic is as simple or as complicated as the underlying queries and results. In 15 years of building web apps with Python ORMs this has never been a problem across many, many different teams.

_hcuq 2y ago

Yep, plus learn SQL and you can use it everywhere. Every language has it's own (multiple) language specific ORMs.

bb88 2y ago

And yet, the Vietnam of Computer Science paper didn't stop the creation of ORM's. There's something fundamentally broken with SQL syntax, and yelling at people to "Just Use SQL" doesn't really help.

mbrumlow 2y ago
Its better than sitting silent and doing nothing. What it does is validate other peoples feelings who feel the same way. And just maybe, that validation will lead to them saying "fuck ORMs" when some junior dev comes in and tries to use one.
- bb88 2y ago
  Fair, but it also reinforces the stereotype that the pro-SQL types are obstinate relics yelling at the youngsters to "Get off my lawn!" There's a pattern of "We can't change X, so we'll write Y that transpiles down to X". It happens often with closed source tools and others that can't or won't implement new languages. Verilog, SQL, Javascript, all fit that bill. E.g. Why is Javascript the only first class language for the browser? For the longest time JS was the only game in town.
sivakon 2y ago
excuse me, what is Vietnam of Computer Science paper? what’s vietnam has to do with it?
- steveklabnik 2y ago
  I am not anti-ORM, but I do know that reference: https://www.odbms.org/wp-content/uploads/2013/11/031.01-Neward-The-Vietnam-of-Computer-Science-June-2006.pdf https://www.odbms.org/wp-content/uploads/2013/11/031.01-Newa...
throwaway19972 2y ago
> There's something fundamentally broken with SQL syntax ? Are you referring to something specific?

carllerche 2y ago

I respect that some prefer just to use SQL, but that isn't where most stand. Also, instead of a reactionary "all ORMs are trash," where ORM probably means different things to different people, maybe you could provide some value to the conversation by providing specific points and/or arguments supporting your feelings about ORMs. At the very least, you could provide some citation to an article that does the summarization.

alain_gilbert 2y ago

I never understood why people are so stubborn about hating on orm. For example I'm familiar with https://gorm.io https://gorm.io and it does save me a lot of time and useless boilerplate. And guess what, if I ever need to make a complex query, I also happen to know SQL, and I'm just going to make a "raw" query https://gorm.io/docs/sql_builder.html#Raw-SQL https://gorm.io/docs/sql_builder.html#Raw-SQL and be done with it. It's not all that hard. edit: the other common complaint usually is: "but I don't know what query the orm is going to make..." Use "Debug" https://gorm.io/docs/session.html#Debug https://gorm.io/docs/session.html#Debug and it will print out exactly what query it's making. Not happy with it? Make a raw query.

throwaway19972 2y ago
> I never understood why people are so stubborn about hating on orm. Objects are just bad abstractions for representing database interactions. They never map cleanly and any attempt to cover up the incoherence introduces further problems. Avoiding boilerplate is understandable, but typed schemas and queries exist without hauling in a full ORM. Of course you can pump out a lot of SQL very quickly with ORMs. There's a lot positive to say about this approach! But you don't tend to end up with code where you can easily tell what's going on.
- Daishiman 2y ago
  > Objects are just bad abstractions for representing database interactions. But they're excellent abstractions for business entities. > Of course you can pump out a lot of SQL very quickly with ORMs. There's a lot positive to say about this approach! But you don't tend to end up with code where you can easily tell what's going on. 15 years building up massive apps with Django and SQLAlchemy and this has never been a problem.
  - throwaway19972 2y ago
    > 15 years building up massive apps with Django and SQLAlchemy and this has never been a problem. I guarantee you it is if the reader isn't already intimately familiar with SQLAlchemy.

jasfi 2y ago

Moving fast is often crucial, but you typically also get more readable code, which is also worth it. A query/DML that is badly optimized is usually very complex, which means that the ORM's syntax isn't a good fit. No problem, since they typically support raw SQL calls, so nothing is really lost. You just have to know when to use the right tool for the job, as always.

throwaway19972 2y ago
> Moving fast is often crucial, but you typically also get more readable code, which is also worth it. I think the exact opposite is true, actually—because of the introduction of stuff like lifecycle hooks it becomes very difficult to figure out how the domain semantics translate to query/execution semantics. Of course some are lighter than that and just e.g. map a table to a domain type (which is much more readable), but that's not typically what catches criticism.

whazor 2y ago

A lot of people think SQL is antiquated, and therefore not worth learning. However, SQL is based upon Relation Algebra, which is the foundation of database optimalisation. Any data querying language/library that is not based on relational algebra will lack the performance. In particular ORMs fall under this category. Having said that, there are other languages/libraries out there that do use the relational algebra constructs.

0x457 2y ago
You still need to know SQL when you're using ORM. You also need to know ORM when you're using one. It's really not that hard to make ORM perform well if you spend some time RTFMing. When was the last time your RDBMS was handling business logic and wasn't just a persistence layer for your application? SQL (the language) isn't composable so you often have a choice of building strings or having many slightly different queries. Anyway, pros of using an ORM outweight it cons in my opinion.

frankjr 2y ago

Nonsense. People use ORMs because the vast majority of queries are trivial. If you need something the ORM doesn't provide sufficient control over, only then you move to raw queries for these cases.

mbrumlow 2y ago
It’s has nothing to do with being simple and everything to do with wha the database looks like at the end of the day. Some ORMs are better than others but if if you have ever looked at a database created by a ORM it always has weird lookup tables, funny names and even with simple objects completely unusable without the ORM. We live in a multi language world. There is a high chance you are going to want to access this data with a different language. This langue is not going to have the same ORM as such you will have a horrid time access the data. ORMs often lay their data out in a way that is highly language dependent. The fact of the matter is SQL is not hard and bypassing the main interface to the database and hand wave it away will always bring you regret when writing any sooty of software other than a toy project. Your best case is you become an expert in the ORM. Resulting in a skill set that does not transfer easy, language locked and the worst of all bottle necks any changes to the data layer to your ORM expert who at first will be proud and happy and end smug and bitchy as all the data layers request changes will simply be redirected to them. When people like me say ORMs are trash it’s much more than any of the surface level rebuttals listed here. It’s about the whole life cycle is your project. Adding up all the places ORMs can fuck you just makes it a bad proposition. God forbid you need to upgrade your database or the ORM version.
- imtringued 2y ago
  Well, different people, different experiences.
  - mbrumlow 2y ago
    Same experience just different time lines.
- alain_gilbert 2y ago

rwaksmunski 2y ago

Yeah, let's trash the 50 year old industry standard and let's obfuscate the interface to one of the most performance sensitive part of an application. Hell, lets build multiple obfuscators for each language, each with it's own astonishing behavior that turns pathological once you actually get usage on the app.

7bit 2y ago
You know whats also a 50 year old industry Standard? Assembler. Yet, Nobody writes it any more.

imtringued 2y ago

Sorry but anyone who needs to build queries dynamically e.g. for extended/advanced search or ACL is going to significantly benefit from being able to seamlessly mix regular code and query logic. Compare that to the old way of concatenating SQL fragments. Shudder.