4 ms·

I find these ORM opinions generally coming from someone who is used to, and is proficient in SQL, and only when they have a complex use-case/operation at hand.

I find these ORM opinions generally coming from someone who is used to, and is proficient in SQL, and only when they have a complex use-case/operation at hand. If you consider a web project, with many developers of different levels of experience, having an ORM is a life saver. Because not everyone is constantly mindful of SQL injections. Because not everyone is constantly mindful of transaction management in requests. Those take experience. In my experience ORMs are great 95% of the time. Those 5% can be extremely painful (I've gotten bitten by ORM Rails transaction nesting problems, and sometimes it frustrates me when I need to make something more complex). But let's not throw away the baby with the bath water. I have had great experiences with Django ORM and SQL Alchemy. Rails ORM goes a long way, but it feels eons behind Django's.

deleted 7y ago
[deleted]
piva00 7y ago
Code reviews are for that, I've taught countless junior developers on how to write better SQL through code reviews. I've introduced them on how to mitigate the common exploits and how powerful SQL can be when needed and I believe they are better engineers because of it. I really don't like using a tool as a crutch to a systemic deficiency of a team, in the long run you are only compounding the problem, the more complex the system gets the more workarounds and gotchas you have with ORMs so it's better to educate developers on how to not depend on them from the get go. Yup, ORMs have their place in some projects but in the majority of what I've worked they brought more pain and confusion than just properly effing learning SQL.
- sergioisidoro 7y ago
  > I really don't like using a tool as a crutch to a systemic deficiency of a team, Very valid point, but then this becomes a discussion of how much you want to create mitigations in the system vs. educating developers to topics of, for example security. The larger a team becomes, the harder it is to police that every single query in your system is sanitized. Still on the security side, Software architecture tell us not to repeat ourselves, and if sanitizing query strings can be done centrally through an ORM, then why shift the responsibility to code review processes that are especially prone to failure due to their human nature? As you said, these kind of become a crutch to people who don't know SQL. People begin to rely on those instead of knowing the underlying mechanisms -- but hey, that's the price of any abstraction. Probably this same argument was used when high level language compilers (analogous to the ORM in this discussion) were introduced.
  - piva00 7y ago
    It will boil down to: how much more complexity having leaky abstractions such as ORM adds to the project compared to teaching others to not make the same mistakes all over the codebase with raw SQL. As with anything related to software design and architecture, it depends, depends on the size of the project, how many teams work on the same codebase, etc. I don't think using an ORM as the sanitisation layer of your SQL queries to be a good enough feature compared to its drawbacks on complexity and abstraction leakage. The object model doesn't serve relational data very well, that is already a first sign and smell for me that ORM should be used in very specific cases instead of as the default go-to solution. Having to deal later on the application lifecycle with partial entities and the likes (anything to do with partial data access compared to the models' defined fields) is really painful when done improperly, which is easy to do, and then we are back on square one having to teach developers how to use an ORM framework properly. Also one thing I really dislike (and that I believe will always increase a system's complexity) is making code less explicit, an ORM layer will make your code flow less accessible, you'll need to know where the layer takes over and where it leaves you to implement more complex use-cases and then you are back to writing SQL queries manually or depending on some set of features from the library implementing the specific use-case you are looking for. I don't hate ORMs but I have mea culpa in using them improperly and learning from my past experiences, nowadays it's really hard for me to justify its usage aside from very simple data access patterns. I say that because in the end you'll always need to reason about what the ORM layer is doing in terms of SQL concepts, translating between those layers in my head is adding another complexity: cognitive load.
jayd16 7y ago
I've never seen anyone who needs an ORM handle transactions correctly in the ORM.
ben509 7y ago
> I find these ORM opinions generally coming from someone who is used to, and is proficient in SQL, and only when they have a complex use-case/operation at hand. I'm reasonably proficient in SQL. My practical blocker with ORMs in general has been that you still have to understand your application obviously, and you have to understand SQL to fix most things, and now you're adding effectively a new language and framework between them. > I have had great experiences with Django ORM and SQL Alchemy. I think the best ORMs aren't ORMs at all, but larger frameworks like Django and Fails, as you're making the investment to learn that framework anyway. And in fairness, I started with Hibernate which is particularly complex, having its own query language. Many ORMs have gone the no-object route and try to directly represent relational concepts, especially jOOQ[1]. That's smart engineering to recognize that problem and minimize it, but at that point it's less of an ORM and more like numpy for the relational algebra. [1]: http://www.jooq.org/ http://www.jooq.org/
gwd 7y ago
> Because not everyone is constantly mindful of SQL injections. I'm a senior developer but just started using SQL seriously a few months ago, and only for my own projects, so don't have much experience; but it's difficult for me to understand this. Both in Python and in Go, every single tutorial tells you how to use parameterized queries, and every answer on StackOverflow has warnings of building SQL queries from normal string operations. Fifteen years ago I could see this being an issue; but is it really possible that in 2019 "inexperienced web developers" manage to write code vulnerable to SQL injection? Is it really only my hard-won paranoia, gained from decades of building operating systems in C, that made me immediately take these warnings to heart? (That's a genuine question, not a rhetorical one.)

deleted 7y ago

[deleted]

piva00 7y ago

Code reviews are for that, I've taught countless junior developers on how to write better SQL through code reviews. I've introduced them on how to mitigate the common exploits and how powerful SQL can be when needed and I believe they are better engineers because of it. I really don't like using a tool as a crutch to a systemic deficiency of a team, in the long run you are only compounding the problem, the more complex the system gets the more workarounds and gotchas you have with ORMs so it's better to educate developers on how to not depend on them from the get go. Yup, ORMs have their place in some projects but in the majority of what I've worked they brought more pain and confusion than just properly effing learning SQL.

sergioisidoro 7y ago
> I really don't like using a tool as a crutch to a systemic deficiency of a team, Very valid point, but then this becomes a discussion of how much you want to create mitigations in the system vs. educating developers to topics of, for example security. The larger a team becomes, the harder it is to police that every single query in your system is sanitized. Still on the security side, Software architecture tell us not to repeat ourselves, and if sanitizing query strings can be done centrally through an ORM, then why shift the responsibility to code review processes that are especially prone to failure due to their human nature? As you said, these kind of become a crutch to people who don't know SQL. People begin to rely on those instead of knowing the underlying mechanisms -- but hey, that's the price of any abstraction. Probably this same argument was used when high level language compilers (analogous to the ORM in this discussion) were introduced.
- piva00 7y ago
  It will boil down to: how much more complexity having leaky abstractions such as ORM adds to the project compared to teaching others to not make the same mistakes all over the codebase with raw SQL. As with anything related to software design and architecture, it depends, depends on the size of the project, how many teams work on the same codebase, etc. I don't think using an ORM as the sanitisation layer of your SQL queries to be a good enough feature compared to its drawbacks on complexity and abstraction leakage. The object model doesn't serve relational data very well, that is already a first sign and smell for me that ORM should be used in very specific cases instead of as the default go-to solution. Having to deal later on the application lifecycle with partial entities and the likes (anything to do with partial data access compared to the models' defined fields) is really painful when done improperly, which is easy to do, and then we are back on square one having to teach developers how to use an ORM framework properly. Also one thing I really dislike (and that I believe will always increase a system's complexity) is making code less explicit, an ORM layer will make your code flow less accessible, you'll need to know where the layer takes over and where it leaves you to implement more complex use-cases and then you are back to writing SQL queries manually or depending on some set of features from the library implementing the specific use-case you are looking for. I don't hate ORMs but I have mea culpa in using them improperly and learning from my past experiences, nowadays it's really hard for me to justify its usage aside from very simple data access patterns. I say that because in the end you'll always need to reason about what the ORM layer is doing in terms of SQL concepts, translating between those layers in my head is adding another complexity: cognitive load.

jayd16 7y ago

I've never seen anyone who needs an ORM handle transactions correctly in the ORM.

ben509 7y ago

> I find these ORM opinions generally coming from someone who is used to, and is proficient in SQL, and only when they have a complex use-case/operation at hand. I'm reasonably proficient in SQL. My practical blocker with ORMs in general has been that you still have to understand your application obviously, and you have to understand SQL to fix most things, and now you're adding effectively a new language and framework between them. > I have had great experiences with Django ORM and SQL Alchemy. I think the best ORMs aren't ORMs at all, but larger frameworks like Django and Fails, as you're making the investment to learn that framework anyway. And in fairness, I started with Hibernate which is particularly complex, having its own query language. Many ORMs have gone the no-object route and try to directly represent relational concepts, especially jOOQ[1]. That's smart engineering to recognize that problem and minimize it, but at that point it's less of an ORM and more like numpy for the relational algebra. [1]: http://www.jooq.org/ http://www.jooq.org/

gwd 7y ago

> Because not everyone is constantly mindful of SQL injections. I'm a senior developer but just started using SQL seriously a few months ago, and only for my own projects, so don't have much experience; but it's difficult for me to understand this. Both in Python and in Go, every single tutorial tells you how to use parameterized queries, and every answer on StackOverflow has warnings of building SQL queries from normal string operations. Fifteen years ago I could see this being an issue; but is it really possible that in 2019 "inexperienced web developers" manage to write code vulnerable to SQL injection? Is it really only my hard-won paranoia, gained from decades of building operating systems in C, that made me immediately take these warnings to heart? (That's a genuine question, not a rhetorical one.)