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