No. I did not. ORM is an "object–relational mapping." It maps data relations onto objects.
https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapp...
> how often do you actually switch databases?
Very often. Virtually all of the systems I write have at least two back-ends to maintain that flexibility. At the very least, I'd like my systems to run well locally for development but also to scale. The easiest way to do that is to e.g. support both SQLite and Postgres, but there are other ways which make sense.
In proprietary settings, I like having a BATNA. The architectural flexibility means I get better prices on hosted services and aren't liable to turning into a cash cow through lock-in. That's savings even if I'm not switching.
> If your object model is already clean and following relational principles, then mapping into that model is exactly what you want.
This is where your thinking broke. A good object model is NOT a relational model, and a good relational model is NOT an object model.
Learn the theory of both. They're both good theories, but they're different.
An ORM makes sense if you want to use an object model, but want the backing store to be an RDBMS.
> But what ORMs should be able to do (and I haven't found one that does this well) is generate SQL migration scripts for you, which you store. Those would be frozen relative to the database schema version, so all the above problems go away.
I believe that's one instantiation of what I wrote: "This may and ideally should have added functionality, for example, around managing and organizing database migrations." It's actually exactly what I was thinking.
Some ORMs do this not badly, actually. Don't let the perfect be the enemy of the good. A simple system which does 90% of the work of generating a migration (with manual verification and tweaks) is often better than a complex one which tries to do 100% of the work.
> The underlying relational model is powerful and elegant. SQL itself is not. SQL is disliked by the founders of the relational model.
Citation required.
In either case, ORMs aren't translating just syntax, but also semantics. That's where the problem lies. If you're not doing that, you're not an ORM.
> Good ORMs let you incorporate the relational model into your code.
You're confused about what an ORM is. ORMs essentially map an RDBMS onto an object model (which an OODBMS does natively). The two models are fundamentally different. It's a translation layer.
Any good database library will let me "incorporate the relational model into my code." That's not an ORM.
