By definition, you only need to do the minimum to move data from one process to another to get things read or written.

That doesn't mean you need an entire system to represent every table as an object-like thing (which is what I assume when people say ORM). It's actually possible to just emit queries to read and write the exact data that's required in the shape that makes sense for the caller.

You can map objects to db updates, and map query results to objects. Neither of those objects needs to have a mapping to actual relations, like how ORMs insist on.

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.

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.

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

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.

> Your database has relational tables.

Mine doesn't, so I don't need an ORM. Plus, I think that when people say ORM, they mean more than just a map from the relational model to the object model and back. They refer to things like hibernate and SQLAlchemy and all the extra stuff that comes with that, like the active record antipattern, and a query builder which successfully encapsulates all trivial queries (which don't need encapsulation) but then as soon as you need to do anything even remotely complicated, the abstraction leaks. I'll be honest, not a fan of ORMs.

There's a difference between mapping database tables to objects and just copying query results into structs.

I kind of agree with this. Data in a database is often relational (hey it might not be, but it's still nice to represent it in a struct sometimes, rather than 10–20 different variables which can change anytime your database changes).

I've been using Go recently, and while I'm not convinced on an active-record style ORM in Go (I don't think the language is dynamic enough, and I'm not the biggest fan of codegen), I've been loading the row data from Postgres into a Result struct (pretty much a 1:1 mapping of the Postgres result set into the struct), and then using another function to load the Result struct into struct with their relationships attached (using tags on the structs to define the relationships between them). This has worked great using reflections & generics.

And chance this is open source?

I’m building something similar and I can’t decide on the relationship struct tag syntax to use. Would be neat to see how others are thinking about it.

ORM by modern standard is not that, it's basically let me interact with the DB without knowing SQL.

Every language need to deserialize results into some object so by definition every language that deal with a DB do some form of ORM. So ORM is meaningless in that context.