3 ms·

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 hel

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?

Izkata 3y ago
The mapping is bi-directional. Query generation is object -> relation, result mapping is relation -> object.
- randomdata 3y ago
  > The mapping is bi-directional. "(Mutation cases are in reverse, but I know you are capable of understanding that without it spelt out in detail)" Guess you were't capable after all. How do tech people manage to be so out to lunch all the time?
  - Izkata 3y ago
    I am the 4th person you've responded to in this thread.
    - randomdata 3y ago
      We already know. There are little username thing-ys that communicate that. Is there something you are trying to add?
      - Izkata 3y ago
        This only makes sense in a back and forth with one other person: > Guess you were't capable after all.
        randomdata 3y ago
        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.
        Izkata 3y ago
        It's the "after all" that implies you thought you were responding to one person the whole time, which is why I corrected that.
        randomdata 3y ago
        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.
simonw 3y ago
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#.
- randomdata 3y ago
  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).
  - simonw 3y ago

Izkata 3y ago

The mapping is bi-directional. Query generation is object -> relation, result mapping is relation -> object.

randomdata 3y ago
> The mapping is bi-directional. "(Mutation cases are in reverse, but I know you are capable of understanding that without it spelt out in detail)" Guess you were't capable after all. How do tech people manage to be so out to lunch all the time?
- Izkata 3y ago
  I am the 4th person you've responded to in this thread.
  - randomdata 3y ago
    We already know. There are little username thing-ys that communicate that. Is there something you are trying to add?
    - Izkata 3y ago
      This only makes sense in a back and forth with one other person: > Guess you were't capable after all.
      - randomdata 3y ago
        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.
        Izkata 3y ago
        It's the "after all" that implies you thought you were responding to one person the whole time, which is why I corrected that.
        randomdata 3y ago
        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.

simonw 3y ago

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

randomdata 3y ago
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).
- simonw 3y ago