3 ms·

Just because you've had bad experiences with ORMs doesn't mean that there are no good ORMs. That's why I bring up how much language/ecosystem does matter. Bad e

Just because you've had bad experiences with ORMs doesn't mean that there are no good ORMs. That's why I bring up how much language/ecosystem does matter. Bad experiences with ORMs come not from ORMs themselves as a concept (it is an extremely broad concept) but from specific ORMs in specific ecosystems. I thought it useful to give examples of specific ORMs in specific ecosystems that bring joy, because throughout these threads you see plenty of hate for ORMs, just like you thought to bring up in response to my post. The auto-CRUD of Django is a joy to have for some types of projects. The type safety and power of C#'s LINQ is easy to underestimate and while there have been times when that power seemed "too magic" and bad versions of EF gave off plenty of bad experiences, there are times of great joy in modern EF. If you haven't experienced these specific ecosystems for yourself, it might be worth doing in a side project somewhere just to give them a shot. I can't guarantee you would find joy in that, but I can suggest that there is possible joy that I know exists to find in such places if you try them with an open mind.

hot_gril 4y ago
It's the concept of an ORM itself, which is a mapping from OOP to relational algebra, both concepts that don't change much between implementations. You have a relational DB with a nice powerful interface already. The ORM tries to abstract that way with a not-so-compatible OOP interface that enforces mediocre schema design. On the practical side, it's common for a system to start needing more impl-specific database optimization eventually, at which point the ORM gets in the way even more. The ORM is ok for small projects, but so is SQL. CoreData is only especially bad because it's confusing to use on top of that. I've used the Django auto-CRUD too.
- WorldMaker 4y ago
  Not all databases use relational algebra. Among other things document databases are increasingly common for a number of types of applications and ORMs can provide good experiences for those types of databases as well. Beyond document databases, I think the "theoretical" mismatch between OOP and Relational is often over-exaggerated/over-stated and most of the mismatch blamed entirely on the wrong direction. For historical reasons, some of which were a love of relational algebra mathematical "purity", relational databases have tended to have problems storing and querying hierarchical and graph data. Hierarchical and graph data are relatively common and somewhat "natural" in OOP: inheritance and polymorphism often rely on hierarchies, and references between objects can easily be complex graphs, including cycles and other complex graph mechanics. Theoretically "pure" relational algebra cannot accommodate that kind of data, it's what keeps the math simple and pretty. There is a clear OOP/Relational mismatch, but it's a lot more to do with that theory problem, and the problem is entirely on the relational side being unable to express practical, common, complex data. If there's something holding things back and enforcing "mediocre schema design", there's a lot of fingers to point at relational algebra itself (and SQL too, for its own ways of trying to be "pure" to relational algebra). In practice, of course, there is no such thing as a "pure" relational database that people actually develop software for and most SQL databases have all sorts of "impure" extensions and tools and some dialects of SQL can surely feel quite powerful but still often have real, interesting holes in the types of data they can describe and query. Though some of those extensions offer escape hatches today, with the increase in JSON support especially in the majority of SQL databases. I know in practice I've anecdotally been seeing an increasing number of cases where ORMs remain relevant and helpful but reliance on SQL-based databases and SQL specifics is diminishing all the more each year. Not that I don't think SQL-based databases are bad at what they do, what they do well they do well, but that there increasingly there's a lot more escape hatches being used to non-SQL data stores (even if just increasing numbers of JSON blobs in an SQL database). There's always more hierarchical and graph data to store and query, and there are better options every year for that kind of data. From my perspective, the best ORMs often don't "abstract" away the relational underpinnings of a relational database: they do their best to help you simplify (if not dumb down) your application's intended data structures to better fit a relational database. I say that as someone with good SQL performance understanding, a love of the theory of pure relational algebra, and a knowledge that when I need to that I can absolutely beat an ORM at hand tuned SQL and "brilliant" relational database schemas. I'm sure our experiences have been vastly different to this point in our careers. I agree with you that there is an ORM/relational mismatch, but I don't expect you to agree with me that my practical experiences continue to tell me that the fault isn't with ORMs in that mismatch.
  - hot_gril 4y ago
    The "R" in ORM means relational, so whatever is working with non-relational DBs is not an ORM. Document store DBs can make sense for some use cases, like very hierarchical data as you said, but it really is a niche use case. You don't often benefit from basing your DB around tall object hierarchies, and you can instead mix in jsonb columns sparingly when they make sense (I'm not a purist about these things). I've been through that ride a few times in different jobs: They start with a relational DB, then someone realizes you could shove everything into a graph where each node can be just about anything, then they do it, then eventually they feel the pain from using what is essentially a weakly-typed DB. Eventually someone whacks everything and goes back to a regular relational schema design, which turns out was a fine way to do it. To put it another way, you could start with the relational way of doing things and probably never encounter enough pain to warrant going to an ORM. The web went through something vaguely similar with HTTP methods. It was cool at some point to conform to a standardized CRUD interface of GET/PUT/PATCH/DELETE on objects, but it's never that simple. Nowadays, plenty of APIs just use POST for everything with freeform requests/responses. I see DELETE sometimes, can't remember the last time I saw PATCH or PUT though.
    - WorldMaker 4y ago
      > The "R" in ORM means relational, so whatever is working with non-relational DBs is not an ORM. It used to mean that. No one that I'm aware of has yet proposed a better name because many of these are the same tools. (EF has some low level support for both SQL-based relational databases and some classes of Document-based databases and keeps exploring ways to improve that.) I think ORM several years back passed the point where the initial acronym was all that important and "ORM" itself is now just the generic name, no acronym at all. We could probably use a better name as an industry, but as the adage goes naming things is one of the hardest problems in software. > To put it another way, you could start with the relational way of doing things and probably never encounter enough pain to warrant going to an ORM. No kidding, and also this is what most of the other threads in this Ask are about and I've never argued against it. What I have argued for, because there aren't as many voices speaking for it, is that the same happens the other way round: You could start with a good ORM in a nice language/ecosystem doing the ORM's comfy way of doing things and probably never encounter enough pain to warrant going directly to SQL (or whatever). Not enough people are saying that. That's most of what I wanted to contribute. I'm not sure why you are battling me on semantics or so adamant that I'm so wrong about "ORMs can be nice sometimes" other than yes it sounds like you can show me where an ORM hurt you once, but that's not my point. ORMs hurt lots people. Not every ORM is great, and not every ORM is great for you. That should all go without saying. ORMs can be nice sometimes. In an Ask full of ORM negativity, I thought I'd offer some positivity. I'm sorry? > The web went through something vaguely similar with HTTP methods. It was cool at some point to conform to a standardized CRUD interface of GET/PUT/PATCH/DELETE on objects, but it's never that simple. Nowadays, plenty of APIs just use POST for everything with freeform requests/responses. I see DELETE sometimes, can't remember the last time I saw PATCH or PUT though. I'm definitely lost here at this aside. I don't actually know what it has to do with the point you are making. For what it is worth as an aside: I see plenty of REST APIs still that focus on POST/GET/PUT/DELETE (that's the direct CRUD analog in CRUD order). I haven't seen a "POST only" API since my rough and tumble PHP youth, but we presumably have very different APIs we work with. (ETA: With the obvious exception of GraphQL, which is its own sort of special, and I don't really think of an as HTTP API.) PATCH is absolutely rare, I'll give you that, but was never a CRUD HTTP verb to begin with. It was always an extension HTTP verb from WebDAV and elsewhere. It is often hard to implement right (PUT is much easier), though increasingly accepted standards like JSON Patch (RFC 6902) and various libraries that support it have started to make it somewhat easier again and I've been seeing PATCH with expected content-type: application/json-patch+json (and only that content type) start to show up again in some APIs.

hot_gril 4y ago

It's the concept of an ORM itself, which is a mapping from OOP to relational algebra, both concepts that don't change much between implementations. You have a relational DB with a nice powerful interface already. The ORM tries to abstract that way with a not-so-compatible OOP interface that enforces mediocre schema design. On the practical side, it's common for a system to start needing more impl-specific database optimization eventually, at which point the ORM gets in the way even more. The ORM is ok for small projects, but so is SQL. CoreData is only especially bad because it's confusing to use on top of that. I've used the Django auto-CRUD too.

WorldMaker 4y ago
Not all databases use relational algebra. Among other things document databases are increasingly common for a number of types of applications and ORMs can provide good experiences for those types of databases as well. Beyond document databases, I think the "theoretical" mismatch between OOP and Relational is often over-exaggerated/over-stated and most of the mismatch blamed entirely on the wrong direction. For historical reasons, some of which were a love of relational algebra mathematical "purity", relational databases have tended to have problems storing and querying hierarchical and graph data. Hierarchical and graph data are relatively common and somewhat "natural" in OOP: inheritance and polymorphism often rely on hierarchies, and references between objects can easily be complex graphs, including cycles and other complex graph mechanics. Theoretically "pure" relational algebra cannot accommodate that kind of data, it's what keeps the math simple and pretty. There is a clear OOP/Relational mismatch, but it's a lot more to do with that theory problem, and the problem is entirely on the relational side being unable to express practical, common, complex data. If there's something holding things back and enforcing "mediocre schema design", there's a lot of fingers to point at relational algebra itself (and SQL too, for its own ways of trying to be "pure" to relational algebra). In practice, of course, there is no such thing as a "pure" relational database that people actually develop software for and most SQL databases have all sorts of "impure" extensions and tools and some dialects of SQL can surely feel quite powerful but still often have real, interesting holes in the types of data they can describe and query. Though some of those extensions offer escape hatches today, with the increase in JSON support especially in the majority of SQL databases. I know in practice I've anecdotally been seeing an increasing number of cases where ORMs remain relevant and helpful but reliance on SQL-based databases and SQL specifics is diminishing all the more each year. Not that I don't think SQL-based databases are bad at what they do, what they do well they do well, but that there increasingly there's a lot more escape hatches being used to non-SQL data stores (even if just increasing numbers of JSON blobs in an SQL database). There's always more hierarchical and graph data to store and query, and there are better options every year for that kind of data. From my perspective, the best ORMs often don't "abstract" away the relational underpinnings of a relational database: they do their best to help you simplify (if not dumb down) your application's intended data structures to better fit a relational database. I say that as someone with good SQL performance understanding, a love of the theory of pure relational algebra, and a knowledge that when I need to that I can absolutely beat an ORM at hand tuned SQL and "brilliant" relational database schemas. I'm sure our experiences have been vastly different to this point in our careers. I agree with you that there is an ORM/relational mismatch, but I don't expect you to agree with me that my practical experiences continue to tell me that the fault isn't with ORMs in that mismatch.
- hot_gril 4y ago
  The "R" in ORM means relational, so whatever is working with non-relational DBs is not an ORM. Document store DBs can make sense for some use cases, like very hierarchical data as you said, but it really is a niche use case. You don't often benefit from basing your DB around tall object hierarchies, and you can instead mix in jsonb columns sparingly when they make sense (I'm not a purist about these things). I've been through that ride a few times in different jobs: They start with a relational DB, then someone realizes you could shove everything into a graph where each node can be just about anything, then they do it, then eventually they feel the pain from using what is essentially a weakly-typed DB. Eventually someone whacks everything and goes back to a regular relational schema design, which turns out was a fine way to do it. To put it another way, you could start with the relational way of doing things and probably never encounter enough pain to warrant going to an ORM. The web went through something vaguely similar with HTTP methods. It was cool at some point to conform to a standardized CRUD interface of GET/PUT/PATCH/DELETE on objects, but it's never that simple. Nowadays, plenty of APIs just use POST for everything with freeform requests/responses. I see DELETE sometimes, can't remember the last time I saw PATCH or PUT though.
  - WorldMaker 4y ago
    > The "R" in ORM means relational, so whatever is working with non-relational DBs is not an ORM. It used to mean that. No one that I'm aware of has yet proposed a better name because many of these are the same tools. (EF has some low level support for both SQL-based relational databases and some classes of Document-based databases and keeps exploring ways to improve that.) I think ORM several years back passed the point where the initial acronym was all that important and "ORM" itself is now just the generic name, no acronym at all. We could probably use a better name as an industry, but as the adage goes naming things is one of the hardest problems in software. > To put it another way, you could start with the relational way of doing things and probably never encounter enough pain to warrant going to an ORM. No kidding, and also this is what most of the other threads in this Ask are about and I've never argued against it. What I have argued for, because there aren't as many voices speaking for it, is that the same happens the other way round: You could start with a good ORM in a nice language/ecosystem doing the ORM's comfy way of doing things and probably never encounter enough pain to warrant going directly to SQL (or whatever). Not enough people are saying that. That's most of what I wanted to contribute. I'm not sure why you are battling me on semantics or so adamant that I'm so wrong about "ORMs can be nice sometimes" other than yes it sounds like you can show me where an ORM hurt you once, but that's not my point. ORMs hurt lots people. Not every ORM is great, and not every ORM is great for you. That should all go without saying. ORMs can be nice sometimes. In an Ask full of ORM negativity, I thought I'd offer some positivity. I'm sorry? > The web went through something vaguely similar with HTTP methods. It was cool at some point to conform to a standardized CRUD interface of GET/PUT/PATCH/DELETE on objects, but it's never that simple. Nowadays, plenty of APIs just use POST for everything with freeform requests/responses. I see DELETE sometimes, can't remember the last time I saw PATCH or PUT though. I'm definitely lost here at this aside. I don't actually know what it has to do with the point you are making. For what it is worth as an aside: I see plenty of REST APIs still that focus on POST/GET/PUT/DELETE (that's the direct CRUD analog in CRUD order). I haven't seen a "POST only" API since my rough and tumble PHP youth, but we presumably have very different APIs we work with. (ETA: With the obvious exception of GraphQL, which is its own sort of special, and I don't really think of an as HTTP API.) PATCH is absolutely rare, I'll give you that, but was never a CRUD HTTP verb to begin with. It was always an extension HTTP verb from WebDAV and elsewhere. It is often hard to implement right (PUT is much easier), though increasingly accepted standards like JSON Patch (RFC 6902) and various libraries that support it have started to make it somewhat easier again and I've been seeing PATCH with expected content-type: application/json-patch+json (and only that content type) start to show up again in some APIs.