Query results are actual, if transitory, relations.

And db updates are either relations or tuples (and a tuple is a relation with cardinality of 1, so...)

You can be pedantic if you like, but this is obviously not what anyone means by "ORM".

Its literally the exact things that ORMs map between: query results -> objects and object changes -> database updates.

No, ORMs abstract away the relational database and present it as if it were some kind of object database. Needing to map query results to structs is just incidental, and is completely missing the point of an ORM.

If copying query results to a list of structs is enough to qualify as an ORM, then the term is so generic as to be entirely useless.

Only for basic objects.

The minute you add relationships your approach becomes unusable.

There is a reason ORMs have persisted for over 30 years.

No it doesn't. Why would relationships matter? You handle the relationships in SQL queries, and just copy query results to structs.

> copy query results to structs

Congratulations, you've invented an ORM.

This is clearly not what anyone means when they say they don't want an ORM.

An ORM library maps an entire relational database to a graph of objects, with the intention of abstracting away the relational database. Copying query results to structs doesn't actually do any of that.

https://en.m.wikipedia.org/wiki/Object%E2%80%93relational_ma...

Majority of ORMs really are nothing more than this.

But then it's nice to have something that generates optimised, database-specific SQL, can handle date/number conversion, supports many-many relationships, converting BLOB to binary streams etc.

That’s 1% of an ORM.

It's at least 30% of most ORMs. And if your homebrew ORM actually gets wide use, it'll grow from there.

Source: Wrote an ORM that other people actually use. Still adding features, twelve years later.