6 ms·

The ORM Debate Still Rages On

37 points by code_pig 10y ago

sevensor 10y ago
I'm not really a web guy, so perhaps I was never the target audience for ORMs. I was surprised by the author's assertion that they seem simple and elegant at first -- maybe it's because I learned SQL first. My first impression of ORMs was, "this looks impossible to do right, in general, and basically untrustworthy. If it's going to work at all, you have to impose harsh limitations on both the 'object' side and the 'relational' side." Having read the article, I'm feeling pretty self-congratulatory. Other than claims to "elegance", what was the motivation for ORMs?
- code_pig 10y ago
  ORMs are essentially abstracting relational data structures to fit an OOP development style. It allows OOP engineers to access a DB without straying far from their comfort zone. That's the sales pitch. In essence, they are rarely ever a good idea. As database drivers have become more simple to manage, and ORM's have tried to become more complex, the value proposition (which I'm loath to suggest existed in the first place) dissipated without any trace.
  - 0x445442 10y ago
    Yeah, SQL mapping frameworks, like MyBatis, seem to be the pragmatic sweet spot for most use cases.
    - zzzeek 10y ago
      Wikipedia: > MyBatis is a Java persistence framework that couples objects with stored procedures or SQL statements using an XML descriptor or annotations IOW an ORM.
  - wdewind 10y ago
    > In essence, they are rarely ever a good idea. I'm not sure I agree with this. There is a massive benefit to having not just your entire engineering org thinking in an object oriented fashion, but also your entire product org. Designers and PMs having a deep understanding of the data model is extremely useful, and to the extent that everyone is already speaking in OO terms (ie: your records are already going to be structured in this fashion), an ORM makes a ton of sense. Not only does it give you abstracted and simplified syntax for common access patterns, it gives you a shim to add in all kinds of stuff like caching, analytics etc., that would be extremely difficult without an ORM. Of course there are pitfalls, mostly poorly constructed queries that don't perform well, but any ORM will let you write raw SQL when you need to. If your models map 1:1 to database tables it's hard to see why you wouldn't want an ORM, and I think there are a lot of great arguments for structuring your data like that (and of course some against it as well).
    - dhd415 10y ago
      >>I'm not sure I agree with this. There is a massive benefit to having not just your entire engineering org thinking in an object oriented fashion, but also your entire product org. Designers and PMs having a deep understanding of the data model is extremely useful, and to the extent that everyone is already speaking in OO terms (ie: your records are already going to be structured in this fashion), an ORM makes a ton of sense. Not only does it give you abstracted and simplified syntax for common access patterns, it gives you a shim to add in all kinds of stuff like caching, analytics etc., that would be extremely difficult without an ORM.<< Whether you use an ORM or not, your data layer can (and generally should) be designed to present a logical data model that may differ from your physical model. While some ORMs offer easy hooks for the addition of caching and analytics, the same is true for a well-designed data layer. I've also seen naive ORM implementations of those kinds of features cause more trouble than they were worth. >>Of course there are pitfalls, mostly poorly constructed queries that don't perform well, but any ORM will let you write raw SQL when you need to.<< While this is technically true, many ORMs force you into database access patterns such a multiple synchronous roundtrips to the database that do not perform well and cannot be resolved simply by dropping to raw SQL. A highly performant data layer is going to interact with the database in ways that ORMs generally cannot.
  - zzzeek 10y ago
    If your application has objects, and talks to a relational database to marshal result rows into instances of those objects, you are using an ORM.
    - NoGravitas 10y ago
      As bgribble said above about Greenspun's Law as applied to ORMs.
  - gnaritas 10y ago
    > ORMs are essentially abstracting relational data structures to fit an OOP development style. It allows OOP engineers to access a DB without straying far from their comfort zone. Not remotely correct; the purpose of an ORM is to map result sets into objects to avoid repetitive hand coding of those mappings for programs that work with objects. It isn't' about a dev's comfort zone, it's about eliminating the need to hand write repetitive mapping code. > In essence, they are rarely ever a good idea. As Also wrong, they are nearly always a good idea as they drastically improve productivity by eliminating tons of manual code that simply isn't necessary to write. You don't seem to understand the value proposition of an ORM enough to be able to critique it.
    - bitcrusher 10y ago
      And so the debate rages on... There are two sides to this, illustrated by the parent post and you post. Ultimately, it comes down to style preference and his little actual tangible TECHNICAL benefit. The benefits to team process/organization can definitely be argued for ( or even against ) but, that is why the debate will rage on for eternity, IMO.
      - gnaritas 10y ago
        If there were no tangible technical benefit ORM's wouldn't be popular. The debate rages on because ORM haters like Climate Change deniers, rarely understand that which they critique. The debate exists because one side is ignorant and cant' tell the difference between using a tool in the wrong situation and a bad tool. ORM's are a great and useful tool and drastically reduce hand written and duplicated code; period, this is a fact and is not debatable. That in some cases they can be misapplied and cause problems doesn't make the tool bad, but it does feed anecdotes that ORM deniers like to pretend is all that exist.
      - runin2k1 10y ago
        The debate is stupid because one side is taking an absolute position against a programming tool that has been used successfully by thousands(millions?) of projects. The funny thing about the anti-ORM-ists position is that they are either: 1) Exclusively embedding raw SQL in their code, and accessing each query result by also hard-coding column names and value types in map look-ups. Maybe this is a "pure" approach, but it is also very brittle as models evolve. Or, 2) They develop their own naive ORM implementation without the self-awareness to realize that is what they are doing. As zzzeek said, "If your application has objects, and talks to a relational database to marshal result rows into instances of those objects, you are using an ORM."
- snomad 10y ago
  One motivation, especially with a code-first work flow, is tying source control and db versioning together. With Entity Framework, you can downgrade the DB structure back to a specific point in time.
  - dhd415 10y ago
    Versioning a database schema is orthogonal to the use of an ORM even though EF is an ORM that also facilitates database schema versioning.
- bgribble 10y ago
  I'm the last person to want to really defend ORMs. But there's a flavor of Greenspun's Tenth Rule [1] that applies... it would go something like "Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through." A decent ORM can help manage the impedance mismatch between SQL and the app language. ORMs are very leaky abstractions and definitely restrict design, but metaprogramming SQL in an app language has its own drawbacks. [1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
  - aeorgnoieang 10y ago
    This has been my experience as well. Being very comfortable with SQL, I initially thought very poorly of ORMs, especially given that my first major exposure was to a "buggy" half-hand-baked implementation. But, like a lot of other things, they definitely exist for a reason and can often be the best option given the particular tradeoffs you're given.
  - Terr_ 10y ago
    That's my experience with a certain 10+ year old piece of PHP enterprise software. Not only is the ORM homegrown, but it started as a data-mapper and somehow ended up being used in a degenerate way like active-record, and has lot of "fun" quirks.
  - lowbloodsugar 10y ago
    >"Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through." Inherited a product that used an ORM. The application was a java application running on multiple hosts and non-sticky sessions. It used session caching, which round-robin load balancing broke silently. Hah, no I'm kidding! It used global caching! Then it was replete with transaction annotations, but it was the wrong transactional level and the transactional annotations were not configured to be used anyway. Then the schema was hard-coded (which I'd usually say is a good thing) because they'd had the database fall over when the ORM attempted to update the schema. Of course the hard-coded schema was missing things and only fixed when the, now manual, updates to the DB caused the queries to outright fail. While the ORM prevented SQL injection, the belief that the ORM somehow handled any kind of injections, meant that the outputs weren't sanitized and XSS injections were not handled at all. So perhaps the problem isn't SQL or ORMs, its that some programmers don't know what the fuck they are doing, and ORMs make it easier to postpone that enlightenment, sometimes indefinitely.
- scarface74 10y ago
  Coming from c# and using Linq: 1. Type safety instead of magic strings 2. Composibiity of queries. 3. Testability - I can mock out the dbcontext in unit test and use an in memory List<T> to test queries without having a database dependencies. But these days, for any new project, my default is to avoid relational databases unless there is good reason for them. Even for BI, my live database is more than likely going to be NoSql and use a combination of CQRS, Event Sourcing, and messaging.
ungzd 10y ago
He is writing it as if ORMs are only for allowing to do queries without knowledge of SQL syntax (which is weird idea) and for forcing database to fit into OOP mindset. SQL (in strings) is not composable at all. Your app rarely has fixed set of queries and almost always need to be able to construct 'where' dynamically, add joins, etc. SQL syntax is especially non-composable, because there once was hype to make programming languages imitate natural languages. In this case, ORM is inevitable if you don't want to have rube goldberg machines of string concatenation everywhere. Non-OO ORMs may be not called "ORM"s but idea is the same. Moreover, Sqlalchemy Core mentioned in article is great example of non-OO ORM: it composes queries and returns result in tuples[1]. [1] http://docs.sqlalchemy.org/en/rel_1_1/core/tutorial.html http://docs.sqlalchemy.org/en/rel_1_1/core/tutorial.html
- akud 10y ago
  Yea, I find that one of the primary benefits of Django's orm is query set methods, which allows me to define and compose query fragments. I've rarely worked on a code base whwe you write a query once and then never change it, the queries are constantly changing. If you have these query fragments that can be composed, it's a lot easier to change the resulting query without changing much code.
- munro 10y ago
  What you're describing is an eDSL (embedded DSL). The syntax of SQL is embedded in the host language, which allows you to use the host language's constructs to compose bits of SQL. It's not 'non-OO ORM' code the developer is writing, it's just SQL with Python syntax. Also I highly recommend SQLAlchemy core! Another example of this would be Pandas for Python, the code the developer writes looks like Python, but the DSL provided actually translate to Fortran & C. There's also a project called Dask which reimplements the backend for Pandas' DSL to run distributed. I wish there was an equivalent for pyspark :)
- wvenable 10y ago
  The composability of ORM queries is a huge benefit to organization and readability -- but not all ORMs handle that well. The article makes a good point; I never think of an ORM as a replacement for SQL -- it can work in concert with it. A lot of my code is much simpler with an ORM than it would be worth out it and in other places it's much simpler with direct SQL than without it. Both can live together harmoniously.
elchief 10y ago
Use an ORM for CRUD, and use a SQL library (like Jooq or QueryDSL for Java) for custom querying
- tomschlick 10y ago
  Exactly. Everyone wants a perfect solution for multiple use cases and that simply doesn't exist. Use what works for the task at hand. For example, Laravel's Eloquent database layer is awesome for the 95% use case. When stuff gets complicated I can drop down to the query builder or raw SQL if things get real hairy.
- craigvn 10y ago
  That's pretty much what I do.
dustingetz 10y ago
Object/relational impedance mismatch is solved by a new class of database built on immutability. If the storage segments are immutable (like git), the query process can be moved out of the central transaction processor and into the horizontally scalable application process (like git). When query engine is embedded in the application process, all the latency and network round trips drop out (like git), which solves in one fell swoop all the intractable optimization problems that ORMs attempt (and fail) to abstract away. One such database is http://www.datomic.com/ http://www.datomic.com/ edit: these databases are relational, acid and competitive with postgres. Strong consistency is achieved by threading through a notion of time (like git) i wrote about it on reddit once, here: https://twitter.com/dustingetz/status/690374292027117568 https://twitter.com/dustingetz/status/690374292027117568
- gnaritas 10y ago
  That doesn't solve the ORM problem at all. Using a non relational database in no way solves the relational object impedance mismatch; it's frankly unrelated.
vinceguidry 10y ago
ORMs are like any technology choice, they allow you to get by with less-skilled engineers. You have to work with the tools you are given, and if the only readily-available devs to hire in your area are all .NET guys, guess what your tech stack is going to look like? Trying to make these decisions based on the merits of the techs themselves doesn't derisk the business, it does the opposite.
- diminoten 10y ago
  I think the problem people have with ORMs includes the fact that it seems like it should let you get away with less-skilled engineers, but the more skilled engineers know that the ORM doesn't save nearly as much time/knowledge as it appears to. It's true, you can have a junior person write up a view simply using the ORM as it appears, but then during code review it'll be valuable for the senior person to come in and say things like, "That query is going to suck, here's how you'd get that data without locking so many tables."
  - gnaritas 10y ago
    If any of your queries are locking tables find a better database; what a senior would do is look at the query log and say hey, you've got an N+1 cascade load issue causing this to be so slow, optimize the query to prefetch the sub data or create a view that has the data you need already and map that. Cascade lazy loading is usually what makes an ORM perform badly and it's merely an indication the dev has a query to optimize, not a sign the ORM is broken.
diminoten 10y ago
I intuitively feel like, in $CURRENT_YEAR, this problem comes up mostly for the people who look for it to be a problem. I work with Django's ORM on a daily basis, and I think being aware of the fact that I can't completely ignore how I interact with my database (e.g. "Well I have an ORM so I shouldn't care" <- this is bad) is enough. The idea that I throw out the proverbial baby here feels like an overcorrection, and while I get how complicated an ORM can become, I think that's more of a result of relying too much on the abstraction. I'm sure most folks here are familiar with Joel Spolsky's "Leaky Abstractions" article. The way I see it, the ORM abstraction is leaky, and that's okay, because the alternatives are all so involved and complex. For some higher-than-fifty percentage of the time however, the abstraction works. That has value.
secstate 10y ago
I think the biggest problem with polemic blogrants like this are that the author has encountered their own personal bankruptcy with ORMs and proceeds to indict the entire enterprise of mapping an object-oriented language environment to a relational object environment. Suggesting that ORMs are awful and no one should use them is effectively premature optimization, and we all know the consequences of that. It is also actively ignoring the history of ORM development. Django's ORM, I know for instance, was developed at a newspaper so that you could go from "feature writer has giant data set and interesting idea about how to visualize it" to "production interactive newspaper article up and allowing people to see their community from different vantage point" within the scope of a day or two. And it worked. And it continues to work. Ignoring the functional aspects of the world or proscribing premature optimization with your opinions is effectively soapbox ranting. You can do it, but the solutions and equity being built on the backs of shitty SQL generated by ORMs are going to just walk right on by.
- astrodust 10y ago
  "I painted myself into the corner of a room. Clearly the roller is at fault! This would never have happened with a brush!" People who bitch about ORMs usually complain for the wrong reasons. Many ORMs are highly opinionated about how to organize their tables, and if you don't adhere to that your code complexity can climb exponentially. If you're constantly going against the grain, maybe you're using the wrong ORM. Keep in mind even ActiveRecord, as ornery as it can be, still has a "revert to manual query" mode. Any well-designed ORM should support that as well.
fergyfresh 10y ago
From what I know about using both it seems like MANY of the benefits were missed. With ORMs you don't really need to worry about database connections or specifying stuff like that. You can also make functions that execute pure SQL in ActiveRecord which I've done before and is in Michael Hartl's Ruby on Rails tutorial. You can also switch between different SQL implementations without worrying about having to refactor stuff, as its usually just an initial configuration/migration. I am not entirely sure but this is from medium so I usually take anything tech related on medium with a grain of salt. If you don't have your tables set-up right you're going to have to do a bunch of weird table joins and stuff, but you can also look into fixing ur databases. DATA STRUCTURES AND TABLE ORGANIZATIONS ARE KING.
default-kramer 10y ago
My biggest problem with ORMs is that you have an object graph that may or may not contain proxies. When you hit a proxy, the ORM will either do a lazy-load or throw an exception. Neither of these is a good default. Either way, the type system becomes useless, and I have to manually check all the call stacks to make sure the object graph is actually loaded. ... but I'm still getting good use out of an ORM right now. I use Entity Framework for the write operations (with lazy-loading) but hand-written SQL for the reads. It works better than anything else I've tried in the past.

37 points by code_pig 10y ago

I'm not really a web guy, so perhaps I was never the target audience for ORMs. I was surprised by the author's assertion that they seem simple and elegant at first -- maybe it's because I learned SQL first. My first impression of ORMs was, "this looks impossible to do right, in general, and basically untrustworthy. If it's going to work at all, you have to impose harsh limitations on both the 'object' side and the 'relational' side." Having read the article, I'm feeling pretty self-congratulatory. Other than claims to "elegance", what was the motivation for ORMs?

code_pig 10y ago
ORMs are essentially abstracting relational data structures to fit an OOP development style. It allows OOP engineers to access a DB without straying far from their comfort zone. That's the sales pitch. In essence, they are rarely ever a good idea. As database drivers have become more simple to manage, and ORM's have tried to become more complex, the value proposition (which I'm loath to suggest existed in the first place) dissipated without any trace.
- 0x445442 10y ago
  Yeah, SQL mapping frameworks, like MyBatis, seem to be the pragmatic sweet spot for most use cases.
  - zzzeek 10y ago
    Wikipedia: > MyBatis is a Java persistence framework that couples objects with stored procedures or SQL statements using an XML descriptor or annotations IOW an ORM.
- wdewind 10y ago
  > In essence, they are rarely ever a good idea. I'm not sure I agree with this. There is a massive benefit to having not just your entire engineering org thinking in an object oriented fashion, but also your entire product org. Designers and PMs having a deep understanding of the data model is extremely useful, and to the extent that everyone is already speaking in OO terms (ie: your records are already going to be structured in this fashion), an ORM makes a ton of sense. Not only does it give you abstracted and simplified syntax for common access patterns, it gives you a shim to add in all kinds of stuff like caching, analytics etc., that would be extremely difficult without an ORM. Of course there are pitfalls, mostly poorly constructed queries that don't perform well, but any ORM will let you write raw SQL when you need to. If your models map 1:1 to database tables it's hard to see why you wouldn't want an ORM, and I think there are a lot of great arguments for structuring your data like that (and of course some against it as well).
  - dhd415 10y ago
    >>I'm not sure I agree with this. There is a massive benefit to having not just your entire engineering org thinking in an object oriented fashion, but also your entire product org. Designers and PMs having a deep understanding of the data model is extremely useful, and to the extent that everyone is already speaking in OO terms (ie: your records are already going to be structured in this fashion), an ORM makes a ton of sense. Not only does it give you abstracted and simplified syntax for common access patterns, it gives you a shim to add in all kinds of stuff like caching, analytics etc., that would be extremely difficult without an ORM.<< Whether you use an ORM or not, your data layer can (and generally should) be designed to present a logical data model that may differ from your physical model. While some ORMs offer easy hooks for the addition of caching and analytics, the same is true for a well-designed data layer. I've also seen naive ORM implementations of those kinds of features cause more trouble than they were worth. >>Of course there are pitfalls, mostly poorly constructed queries that don't perform well, but any ORM will let you write raw SQL when you need to.<< While this is technically true, many ORMs force you into database access patterns such a multiple synchronous roundtrips to the database that do not perform well and cannot be resolved simply by dropping to raw SQL. A highly performant data layer is going to interact with the database in ways that ORMs generally cannot.
- zzzeek 10y ago
  If your application has objects, and talks to a relational database to marshal result rows into instances of those objects, you are using an ORM.
  - NoGravitas 10y ago
    As bgribble said above about Greenspun's Law as applied to ORMs.
- gnaritas 10y ago
  > ORMs are essentially abstracting relational data structures to fit an OOP development style. It allows OOP engineers to access a DB without straying far from their comfort zone. Not remotely correct; the purpose of an ORM is to map result sets into objects to avoid repetitive hand coding of those mappings for programs that work with objects. It isn't' about a dev's comfort zone, it's about eliminating the need to hand write repetitive mapping code. > In essence, they are rarely ever a good idea. As Also wrong, they are nearly always a good idea as they drastically improve productivity by eliminating tons of manual code that simply isn't necessary to write. You don't seem to understand the value proposition of an ORM enough to be able to critique it.
  - bitcrusher 10y ago
    And so the debate rages on... There are two sides to this, illustrated by the parent post and you post. Ultimately, it comes down to style preference and his little actual tangible TECHNICAL benefit. The benefits to team process/organization can definitely be argued for ( or even against ) but, that is why the debate will rage on for eternity, IMO.
    - gnaritas 10y ago
      If there were no tangible technical benefit ORM's wouldn't be popular. The debate rages on because ORM haters like Climate Change deniers, rarely understand that which they critique. The debate exists because one side is ignorant and cant' tell the difference between using a tool in the wrong situation and a bad tool. ORM's are a great and useful tool and drastically reduce hand written and duplicated code; period, this is a fact and is not debatable. That in some cases they can be misapplied and cause problems doesn't make the tool bad, but it does feed anecdotes that ORM deniers like to pretend is all that exist.
    - runin2k1 10y ago
      The debate is stupid because one side is taking an absolute position against a programming tool that has been used successfully by thousands(millions?) of projects. The funny thing about the anti-ORM-ists position is that they are either: 1) Exclusively embedding raw SQL in their code, and accessing each query result by also hard-coding column names and value types in map look-ups. Maybe this is a "pure" approach, but it is also very brittle as models evolve. Or, 2) They develop their own naive ORM implementation without the self-awareness to realize that is what they are doing. As zzzeek said, "If your application has objects, and talks to a relational database to marshal result rows into instances of those objects, you are using an ORM."
snomad 10y ago
One motivation, especially with a code-first work flow, is tying source control and db versioning together. With Entity Framework, you can downgrade the DB structure back to a specific point in time.
- dhd415 10y ago
  Versioning a database schema is orthogonal to the use of an ORM even though EF is an ORM that also facilitates database schema versioning.
bgribble 10y ago
I'm the last person to want to really defend ORMs. But there's a flavor of Greenspun's Tenth Rule [1] that applies... it would go something like "Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through." A decent ORM can help manage the impedance mismatch between SQL and the app language. ORMs are very leaky abstractions and definitely restrict design, but metaprogramming SQL in an app language has its own drawbacks. [1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
- aeorgnoieang 10y ago
  This has been my experience as well. Being very comfortable with SQL, I initially thought very poorly of ORMs, especially given that my first major exposure was to a "buggy" half-hand-baked implementation. But, like a lot of other things, they definitely exist for a reason and can often be the best option given the particular tradeoffs you're given.
- Terr_ 10y ago
  That's my experience with a certain 10+ year old piece of PHP enterprise software. Not only is the ORM homegrown, but it started as a data-mapper and somehow ended up being used in a degenerate way like active-record, and has lot of "fun" quirks.
- lowbloodsugar 10y ago
  >"Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through." Inherited a product that used an ORM. The application was a java application running on multiple hosts and non-sticky sessions. It used session caching, which round-robin load balancing broke silently. Hah, no I'm kidding! It used global caching! Then it was replete with transaction annotations, but it was the wrong transactional level and the transactional annotations were not configured to be used anyway. Then the schema was hard-coded (which I'd usually say is a good thing) because they'd had the database fall over when the ORM attempted to update the schema. Of course the hard-coded schema was missing things and only fixed when the, now manual, updates to the DB caused the queries to outright fail. While the ORM prevented SQL injection, the belief that the ORM somehow handled any kind of injections, meant that the outputs weren't sanitized and XSS injections were not handled at all. So perhaps the problem isn't SQL or ORMs, its that some programmers don't know what the fuck they are doing, and ORMs make it easier to postpone that enlightenment, sometimes indefinitely.
scarface74 10y ago
Coming from c# and using Linq: 1. Type safety instead of magic strings 2. Composibiity of queries. 3. Testability - I can mock out the dbcontext in unit test and use an in memory List<T> to test queries without having a database dependencies. But these days, for any new project, my default is to avoid relational databases unless there is good reason for them. Even for BI, my live database is more than likely going to be NoSql and use a combination of CQRS, Event Sourcing, and messaging.

ungzd 10y ago

He is writing it as if ORMs are only for allowing to do queries without knowledge of SQL syntax (which is weird idea) and for forcing database to fit into OOP mindset. SQL (in strings) is not composable at all. Your app rarely has fixed set of queries and almost always need to be able to construct 'where' dynamically, add joins, etc. SQL syntax is especially non-composable, because there once was hype to make programming languages imitate natural languages. In this case, ORM is inevitable if you don't want to have rube goldberg machines of string concatenation everywhere. Non-OO ORMs may be not called "ORM"s but idea is the same. Moreover, Sqlalchemy Core mentioned in article is great example of non-OO ORM: it composes queries and returns result in tuples[1]. [1] http://docs.sqlalchemy.org/en/rel_1_1/core/tutorial.html http://docs.sqlalchemy.org/en/rel_1_1/core/tutorial.html

akud 10y ago
Yea, I find that one of the primary benefits of Django's orm is query set methods, which allows me to define and compose query fragments. I've rarely worked on a code base whwe you write a query once and then never change it, the queries are constantly changing. If you have these query fragments that can be composed, it's a lot easier to change the resulting query without changing much code.
munro 10y ago
What you're describing is an eDSL (embedded DSL). The syntax of SQL is embedded in the host language, which allows you to use the host language's constructs to compose bits of SQL. It's not 'non-OO ORM' code the developer is writing, it's just SQL with Python syntax. Also I highly recommend SQLAlchemy core! Another example of this would be Pandas for Python, the code the developer writes looks like Python, but the DSL provided actually translate to Fortran & C. There's also a project called Dask which reimplements the backend for Pandas' DSL to run distributed. I wish there was an equivalent for pyspark :)
wvenable 10y ago
The composability of ORM queries is a huge benefit to organization and readability -- but not all ORMs handle that well. The article makes a good point; I never think of an ORM as a replacement for SQL -- it can work in concert with it. A lot of my code is much simpler with an ORM than it would be worth out it and in other places it's much simpler with direct SQL than without it. Both can live together harmoniously.

elchief 10y ago

Use an ORM for CRUD, and use a SQL library (like Jooq or QueryDSL for Java) for custom querying

tomschlick 10y ago
Exactly. Everyone wants a perfect solution for multiple use cases and that simply doesn't exist. Use what works for the task at hand. For example, Laravel's Eloquent database layer is awesome for the 95% use case. When stuff gets complicated I can drop down to the query builder or raw SQL if things get real hairy.
craigvn 10y ago
That's pretty much what I do.

dustingetz 10y ago

Object/relational impedance mismatch is solved by a new class of database built on immutability. If the storage segments are immutable (like git), the query process can be moved out of the central transaction processor and into the horizontally scalable application process (like git). When query engine is embedded in the application process, all the latency and network round trips drop out (like git), which solves in one fell swoop all the intractable optimization problems that ORMs attempt (and fail) to abstract away. One such database is http://www.datomic.com/ http://www.datomic.com/ edit: these databases are relational, acid and competitive with postgres. Strong consistency is achieved by threading through a notion of time (like git) i wrote about it on reddit once, here: https://twitter.com/dustingetz/status/690374292027117568 https://twitter.com/dustingetz/status/690374292027117568

gnaritas 10y ago
That doesn't solve the ORM problem at all. Using a non relational database in no way solves the relational object impedance mismatch; it's frankly unrelated.

vinceguidry 10y ago

ORMs are like any technology choice, they allow you to get by with less-skilled engineers. You have to work with the tools you are given, and if the only readily-available devs to hire in your area are all .NET guys, guess what your tech stack is going to look like? Trying to make these decisions based on the merits of the techs themselves doesn't derisk the business, it does the opposite.

diminoten 10y ago
I think the problem people have with ORMs includes the fact that it seems like it should let you get away with less-skilled engineers, but the more skilled engineers know that the ORM doesn't save nearly as much time/knowledge as it appears to. It's true, you can have a junior person write up a view simply using the ORM as it appears, but then during code review it'll be valuable for the senior person to come in and say things like, "That query is going to suck, here's how you'd get that data without locking so many tables."
- gnaritas 10y ago
  If any of your queries are locking tables find a better database; what a senior would do is look at the query log and say hey, you've got an N+1 cascade load issue causing this to be so slow, optimize the query to prefetch the sub data or create a view that has the data you need already and map that. Cascade lazy loading is usually what makes an ORM perform badly and it's merely an indication the dev has a query to optimize, not a sign the ORM is broken.

diminoten 10y ago

I intuitively feel like, in $CURRENT_YEAR, this problem comes up mostly for the people who look for it to be a problem. I work with Django's ORM on a daily basis, and I think being aware of the fact that I can't completely ignore how I interact with my database (e.g. "Well I have an ORM so I shouldn't care" <- this is bad) is enough. The idea that I throw out the proverbial baby here feels like an overcorrection, and while I get how complicated an ORM can become, I think that's more of a result of relying too much on the abstraction. I'm sure most folks here are familiar with Joel Spolsky's "Leaky Abstractions" article. The way I see it, the ORM abstraction is leaky, and that's okay, because the alternatives are all so involved and complex. For some higher-than-fifty percentage of the time however, the abstraction works. That has value.

secstate 10y ago

I think the biggest problem with polemic blogrants like this are that the author has encountered their own personal bankruptcy with ORMs and proceeds to indict the entire enterprise of mapping an object-oriented language environment to a relational object environment. Suggesting that ORMs are awful and no one should use them is effectively premature optimization, and we all know the consequences of that. It is also actively ignoring the history of ORM development. Django's ORM, I know for instance, was developed at a newspaper so that you could go from "feature writer has giant data set and interesting idea about how to visualize it" to "production interactive newspaper article up and allowing people to see their community from different vantage point" within the scope of a day or two. And it worked. And it continues to work. Ignoring the functional aspects of the world or proscribing premature optimization with your opinions is effectively soapbox ranting. You can do it, but the solutions and equity being built on the backs of shitty SQL generated by ORMs are going to just walk right on by.

astrodust 10y ago
"I painted myself into the corner of a room. Clearly the roller is at fault! This would never have happened with a brush!" People who bitch about ORMs usually complain for the wrong reasons. Many ORMs are highly opinionated about how to organize their tables, and if you don't adhere to that your code complexity can climb exponentially. If you're constantly going against the grain, maybe you're using the wrong ORM. Keep in mind even ActiveRecord, as ornery as it can be, still has a "revert to manual query" mode. Any well-designed ORM should support that as well.

fergyfresh 10y ago

From what I know about using both it seems like MANY of the benefits were missed. With ORMs you don't really need to worry about database connections or specifying stuff like that. You can also make functions that execute pure SQL in ActiveRecord which I've done before and is in Michael Hartl's Ruby on Rails tutorial. You can also switch between different SQL implementations without worrying about having to refactor stuff, as its usually just an initial configuration/migration. I am not entirely sure but this is from medium so I usually take anything tech related on medium with a grain of salt. If you don't have your tables set-up right you're going to have to do a bunch of weird table joins and stuff, but you can also look into fixing ur databases. DATA STRUCTURES AND TABLE ORGANIZATIONS ARE KING.

default-kramer 10y ago

My biggest problem with ORMs is that you have an object graph that may or may not contain proxies. When you hit a proxy, the ORM will either do a lazy-load or throw an exception. Neither of these is a good default. Either way, the type system becomes useless, and I have to manually check all the call stacks to make sure the object graph is actually loaded. ... but I'm still getting good use out of an ORM right now. I use Entity Framework for the write operations (with lazy-loading) but hand-written SQL for the reads. It works better than anything else I've tried in the past.