ORM is the act of mapping relations (sets of tuples) to objects (graph structures). How could query building be a part of that?
There are ORM toolkits that help produce the code to perform that mapping to save you from doing it by hand (although you can do it by hand, if you so wish!), but not even they could shove query building in the middle. Query execution has to happen before ORM can take place. You cannot perform ORM until you have the relation already in hand. (Mutation cases are in reverse, but I know you are capable of understanding that without it spelt out in detail)
What would it even mean for ORM to include query building?
If I'm reading you right, you seem to be saying that database helper libraries often include both query building and ORM toolkit features, usually along with other features like database migration management. Which is very much true. But why would you call one feature by the name of another? If you call query building ORM, is ORM best called database migration?
No...? The assertion about being able to understand the reverse case went out to anyone reading the comment. This is clearly a community forum, not some kind of private messaging system. Comments are not directed towards anyone in particular.
Stop and think. If you actually did somehow mistakenly believe it was a one-on-one with another person, why would you but your head into the conversation? That would be completely illogical. There is a curious contraction here.
You can rephrase it that way, sure: "After all this (being explicitly told that there is an inverse case), you still weren't capable of understanding what was written."
The first half of your comment does not logically precede that, though. There is no such implication.
You're the only person I've encountered that has expressed a strong opinion that the query building part of an ORM should be considered separate from the rest of the ORM.
Do you have any examples of open source ORM libraries that stick to the terminology you are advocating here? I've not seen one myself.
Maybe this is partly an ecosystem thing. What ecosystems do you mainly work in? I'm primarily Python with a bit of JavaScript, so I don't have much exposure to ORM terminology in Java or C#.
Irrespective of naming, can we at least agree that there are, at minimum, two completely different features being spoken about here?
1. A feature that prepares a query to send to the database engine.
2. A feature that transforms data structures from one representation to another.
And we agree that these are independent? You can prepare a query without data transformation, and you can perform data transformation without preparing a query? I think we can prove that, if you are still unconvinced.
Okay, so that just leaves naming. What should we call these distinct features?
Here are my suggestions:
1. Query building. Building a query is the operation being performed.
2. Object-relational mapping; ORM for short. Mapping objects to relations (and vice-versa) is the operation being performed.
These descriptive names seem well suited to the task in my opinion, but I am open to better ideas. What have you got?
Now, there is something else in the wild that we haven't really talked about yet, but may be that which that you are alluding to. Another abstraction, or pattern if you will, that rests above (to use my suggested terms, bear with me) both query building and objet-relational mapping to unify them into some kind of cohesive system that actively manages records. This is where it starts to become sensible to consider (again, using my suggested terms for lack of anything better) query building and ORM intertwined.
I would suggest we call that active record. In large part because that's what we already call it. In fact, what is probably the most popular and well known active record library is literally named ActiveRecord, so-named because it was designed after the active record pattern. But, again, open to better ideas.
> What ecosystems do you mainly work in?
Python, Javascript (well, Typescript, if you want to go there).
My mental model of what an ORM does is that it provides you with an object-oriented API that disguises some of the underlying mechanics of how the SQL queries work.
That's an object-oriented API that builds a query that looks something like this:
SELECT
"blog_entry"."id",
"blog_entry"."created",
"blog_entry"."slug",
"blog_entry"."metadata",
"blog_entry"."search_document",
"blog_entry"."import_ref",
"blog_entry"."card_image",
"blog_entry"."series_id",
"blog_entry"."title",
"blog_entry"."body",
"blog_entry"."tweet_html",
"blog_entry"."extra_head_html",
"blog_entry"."custom_template"
FROM
"blog_entry"
WHERE
(
"blog_entry"."created" >= "2021-01-01 00:00:00"
AND NOT (
EXISTS(
SELECT
1 AS "a"
FROM
"blog_entry_tags" U1
INNER JOIN "blog_tag" U2 ON (U1."tag_id" = U2."id")
WHERE
(
U2."tag" = 'python'
AND U1."entry_id" = ("blog_entry"."id")
)
LIMIT
1
)
)
)
ORDER BY
"blog_entry"."created" DESC
After executing the query it uses the returned data to populate multiple Entry objects (sometimes with clever tricks to fill in related objects so they don't have to be fetched separately, see select_related() and prefetch_related().
But the bit that builds the SQL SELECT query and the bit that populates the returned objects is pretty tightly coupled.
That is what was described originally by the active record paper. Traditionally it has been called the active record pattern, but if we'd rather call that ORM today, despite the misnomer, so be it. I couldn't care less.
But, I do care about being able to precisely communicate with other people. What are we going to call the other things?
There are ORM toolkits that help produce the code to perform that mapping to save you from doing it by hand (although you can do it by hand, if you so wish!), but not even they could shove query building in the middle. Query execution has to happen before ORM can take place. You cannot perform ORM until you have the relation already in hand. (Mutation cases are in reverse, but I know you are capable of understanding that without it spelt out in detail)
What would it even mean for ORM to include query building?
If I'm reading you right, you seem to be saying that database helper libraries often include both query building and ORM toolkit features, usually along with other features like database migration management. Which is very much true. But why would you call one feature by the name of another? If you call query building ORM, is ORM best called database migration?