Re: VMS x86-64 database server

On 7/11/2025 8:35 PM, Lawrence D'Oliveiro wrote:

On Fri, 11 Jul 2025 19:43:59 -0400, Arne Vajhøj wrote:

The main point of ORM is to avoid boilerplate code like iterating and
result sets and stuff them into the object data structure.

 Those are just up to the DB API, taking advantage of features of the
language. Like the query iterator I posted elsewhere.

The language can make it more or less cumbersome.
But the ORM makes it completely go away.
Even for complex object structures.

The point of the ORM is supposed to be to get away from SQL altogether,
and let you operate in terms of language-native objects.

ORM cannot read minds.
Somehow the code need to tell the ORM what query to make.
That us usually ORM QL, SQL or equivalent fluent API.
But it is:
   some form of query --(ORM)--> object structure
not:
   some form of query --(application code)--> object structure

Some ORM's operate with a dirty concept and automatically save changed
objects.

 How do you map between OO objects and SQL tables?

There are 3 common approaches: attributes/annotations, config file
and convention.

                                                      That’s called the
“impedance mismatch”, which tends to cause more problems than it solves.

20 years ago there were some pain points. But solution has been found
since then.

Some ORM's provide identical syntax for doing things even though the
underlying databases have different SQL syntax for it, which help making
the application more portable.

 More commonly you want to support different programming languages
accessing the same back-end DBMS containing the common enterprise-wide
data, rather than move a program between different back-end DBMSes. ORMs
are language-specific, so they don’t help with that.

True.
But it does make it easier to change database. Which also happens
occasionally.
Arne