3 ms·

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

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
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. Take Django for example: Entry.objects.filter(created__year__gte=2024).exclude(tags__tag="python") 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.
- randomdata 3y ago
  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?

simonw 3y ago

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. Take Django for example: Entry.objects.filter(created__year__gte=2024).exclude(tags__tag="python") 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.

randomdata 3y ago
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?