[Arch-TK]

> That depends on the rest of your code.

No, I am asking about your hypothetical "bare bones" "ORM" which explicitly _doens't_ have anything beyond "object mapping".

> When your code merely does that, what do you call it?

Certainly not _object_ mapping. It's something between regular "data mapping" and "completely worthless." If the thing you get out of it is not something representing an object from your object model.

> ORM alone is not sufficient for these patterns.

You are talking about a definition of ORM which is at odds with any definition of ORM that I am personally aware of.

Classical ORMs focus almost entirely on providing proxy objects which represent your object model and which back accesses with additional queries.

> Unlikely. SQL is mentioned in the headline for a reason. Nobody uses relational databases in the real world.

SQL is a query language for relational databases. Unless you have another definition for "SQL" or "relational database" which is at odds with common parlance.

> I understand why you might think a relational database is necessary given that ORM stands for Object Relational Mapping, but as ORM operates on data, not databases, the data can be relational even if the backing database isn't. It simply becomes another mapping step to see them become compatible.

While certainly an ORM maps between an object model and a relational model, the fact that this could be done with something other than a relational database seems completely irrelevant to anything in this discussion.

You seem to be taking the term "Object Relational Mapping" splitting it into its constituent parts, looking at the definitions of those terms, and then assuming that the definition for the whole term is just a simple combination of the individual terms.

This is akin to me claiming that OOP doesn't require a programming language or computers, and can merely involve me buying or otherwise procuring a bunch of things (objects) and then setting them up (programming) in the form of a Rube Goldberg machine in order to perform calculations.

My earlier statements regarding the example code existed to point out that the mere act of taking some relational data and somehow converting it to objects in your object model is not "mapping" in any meaningful sense because the resulting objects would be incomplete, and in some cases would not even be able to be constructed from arbitrary relational data.

The mere act of instantiating a partial object graph from relational data is _not_ "ORM", in the same sense that writing and calling functions is not functional programming.

[win311fwg]

> I am asking about your hypothetical "bare bones" "ORM"

What does "bare bones ORM" mean? That seems like saying "bare bones sort", but like sort it seems to me like it is either something that happens or something that doesn't happen. You either map objects and relations or you don't. Are you imagining that there is some way to partially map relations and objects but somehow not go all the way? I admittedly cannot picture what that would look like. What would the purpose be?

> SQL is a query language for relational databases.

No. SQL is not for relational databases. This is most obviously observed by the fact that SQL is centred around tables instead of relations. That naming isn't just a marketing gimmick. Tables are technically different from relations. Codd, inventor of the relational model, spent a lot of time writing about why SQL isn't relational if you want a more in-depth technical explanation, but suffice to say that ORMs and SQL are not directly compatible. Although obviously they can work together if you layer in additional functionality. You can make any data shape work with another if you provide some kind of mapping between them.

[Arch-TK]

> Are you imagining that there is some way to partially map relations and objects but somehow not go all the way? I admittedly cannot picture what that would look like. What would the purpose be?

I am asking _you_ what _you_ are trying to claim here.

If you have a class such as:

    @dataclass(frozen=True)
    class User
        name: str
        friends: set[User]

I am trying to figure out how your described model maps it from partial information such as:

"user" (user_name) subset:

    ("Fred")
    ("Jeff")
    ("Bob")

"friend" (user_name, friend_name) subset:

    ("Fred", "Jeff")
    ("Fred", "Bob")

Because to "map" this to the object model, your relational mapper would presumably need to do this:

    fred = User("Fred", { User("Jeff", set()), User("Bob", set()) })

But from the above partial information, you don't know if Jeff or Bob have friends.

This breaks down further when you add more to the users tuple set, e.g. let's add a required "surname" field.

    ("Fred", "Robinson")

Now mapping the above would result in:

    fred = User("Fred", "Robinson", { User("Jeff", ???, set()), User("Bob", ???, set()) })

Unlike with the empty "friends" set case, there's _nothing_ you can put in the names which is correct unless you force those fields to be nullable. This is basically unmappable.

I am asking how _your_ idea of an ORM which doesn't handle querying (or if you want to use relational terminology, evaluating relational algebra expressions) works. Presumably you will claim that it will only map data which is mappable, which is wonderfully useless. But then you're just describing the concept of mapping, and not "an ORM" which is a tool which handles this concept for you.

> No. SQL is not for relational databases. This is most obviously observed by the fact that SQL is centred around tables instead of relations.

This is a weird argument. Relational data doesn't centre around relations, it centres around sets of tuples, the relations are an external concept which makes interpreting the dataset useful.

> Codd, inventor of the relational model, spent a lot of time writing about why SQL isn't relational if you want a more in-depth technical explanation

E. F. Codd complained that SQL databases aren't a faithful representation of the relational model, and that's accurate. His complaints were with the following (cited verbatim):

"

* Flaw No. 1: it permits duplicate rows in relations;

* Flaw No. 2: it supports an inadequately defined kind of nesting of a query within a query;

* Flaw No. 3: it does not adequately support three-valued logic, let alone four.

"

Regardless, their use of "tables" has nothing to do with whether they're relational or not. Codd's complaints are to do with the fact SQL databases use bags instead of sets, that SQL doesn't perfectly represent certain relational semantics because the language was rushed and half-assed, and that they handle MAYBE (NULL) half-assedly and lack support for "inapplicable" values.

The thing to note here is that these flaws, if fixed, would have no impact on the OR impedance mismatch, or the ORM problem.

> but suffice to say that ORMs and SQL are not directly compatible.

You are making an appeal to definition here, specifically the definition of the words "Object", "Relational", and "Mapper". "ORM" is itself a marketing term which was coined at some point in the 90s. This was to describe an approach people were taking to trying to map objects in languages such as C++ to _tables_ in "relational databases" of the time.

The relational databases which were being mapped had tables because that's what the papers of the time[^1] talk about.

The earliest paper I can find that talks about "mapping" describes it in terms of query generation and proxy objects[^2]. Although it does describe a "Light Object Mapping" approach which distinctly doesn't model relationships or use query generation, and uses "basic objects" (which do not actually represent an object model, and are instead just data transfer objects (DTOs)). But what "Light Object Mapping" means here is specifically: "just write your own SQL and map it to DTOs by ahnd" rather than describing any automated approach for the problem, which is precisely how it's the only option that gets away with not having a query generator.

It's kind of funny seeing how far back the "impedance mismatch is imaginary" mindset reaches, because it's present in this paper too. A paper which then goes on to explain the significant complexity of this problem and brushes over many of the even harder parts.

[^1]: http://infolab.stanford.edu/pub/keller/1993/sigmod-93-persis... [^2]: https://www.freeengineeringbooks.com/Ebooks/objectRelational...

[win311fwg]

> I am asking _you_ what _you_ are trying to claim here.

I claim nothing about "bare bones", so, again, you must clarify what you mean by it before I can do anything with it.

> I am trying to figure out how your described model maps it from partial information...

That's up to the implementation to figure out. ORM isn't a specific algorithm. Is that the source of your confusion?

> it centres around sets of tuples

Whereas SQL does not. You can, of course, map SQL structures onto relations, which may be why you see SQL as being relational, but that's true of any database. You can take a document database and map it to sets of tuples too. Calling a document database a relational database because it can be mapped to sets of tuples is a stretch, however. Relational databases are natively relational, not just able to represent relations.

[Arch-TK]

Look, it's pretty clear to me that you're either not reading half of what I write, or choosing to ignore it. I am not particularly interested in speaking to a wall.

> I claim nothing about "bare bones", so, again, you must clarify what you mean by it before I can do anything with it.

I shouldn't need to spell this out, but I am not insinuating anything negative or positive about your approach by calling the description you gave initially as "bare bones". I am simply using "bare bones" as a shorthand to refer to your definition of ORM.

You are claiming that implementing an ORM doesn't require query building, I am claiming that it does. I am calling your proposed ORM that doesn't require query building "bare bones", just as a shorthand to avoid saying "ORM that doesn't do any query building". I hope this makes things clear for you.

> That's up to the implementation to figure out. ORM isn't a specific algorithm. Is that the source of your confusion?

We are talking about _an_ ORM. As I clearly stated in my original comment, and as is being described in TFA. _An_ ORM is a tool which presents a "relational" database's (e.g. PostgreSQL, SQLite, MariaDB, ...) contents as an object graph. With the _external_ relationships (as in the relational model) modelled as _internal_ relationships (as in object graphs).

I am not talking about abstract "object <-> relational mapping" in a vacuum, I am talking about the specific thing that people mean when in 2026 they say "I am using an ORM".

> Whereas SQL does not.

SQL centres around bags of tuples, so you are indeed right that it's not quite truly relational, as was Codd, as I acknowledged. But that doesn't make any impact on what people mean when they say "ORM" in modern day programming parlance. So please stop appealing to an irrelevant definition.

> Relational databases are natively relational, not just able to represent relations.

What do you think this even means? The fact that SQL has bags of tuples just means that if you want it to follow a relational model, you must merely ensure that you enforce these bags to be sets. At this point the remaining complaints by Codd don't have an impact on the fact that, insofar as you don't hit those specific niche limitations, you are faithfully representing a relational model at least in your data.

Relationships in the relational model are not internal, they are external. This is one of the reasons for the OR mismatch. It's counterintuitive that object graphs represent relations internally, and relational models do so externally, at least when phrased like that, but it's inherently true.

The fact that graphs represent relationships also doesn't make graph databases or object databases relational. I would have assumed this was clear from what I wrote so far, but as I already established, I suspect you're not actually reading half of what I am writing, so it maybe isn't so surprising that you think I am ignorant of these things.

If I only read select paragraphs of what Codd wrote, I might also think that he was ignorant of his own model, but instead I kept reading what he wrote until I was confident in my understanding of it. I suggest you do the same if you wish to have a productive conversation on any topic online.