> 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 propose

> 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.