351–354 of 354 posts
The generator takes a single specification and produces everything needed for the server, client, and databases (SQLite, Oracle, in-memory, etc.) to stay perfectly in sync.
It has worked really well for us and has been a huge productivity boost.
Earlier quoted context omitted.
> 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 info…
> 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 Wher…
> 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.
Earlier quoted context omitted.
> I don't think providing 90% of the structure you need is a failed abstraction. It is, when the "10%" is the actual hot queries that your system will use the most? Code right now "is so cheap". You can provide your favourite LLM with your database schema, and some domain comments, and ask it a query to fetch/update data, and it will generate somewhat sane queries for you. You can then inspect those queries yourself,…
Even if you replace ORM generated queries with hand generated queries or LLM generated queries you're still missing a huge chunk of functionality provided by an ORM. For my projects I would say that the majority of the value an ORM delivers occurs after the query has returned from the database . But for some reason everyone focuses on query generation as if it were the only feature of an ORM.
I have a lot of fighting against Spring / Hibernate for this. It doesn't let me do cartesian product because the query builder thinks it needs a cartesian product, I can't select only some of the columns without making a whole new data structure while fighting the ORM that thinks one table = one class, can't query from a joined table.
I don't have any issue with mapping using these query builders like jooq which lets you use generated class from the live db for simple use case and give you other mechanism for querying weird joins or aggregates.
What sort of perks of ORM after the query has returned do you find to be helpful?