From: arne@vajhoej.dk   
      
   On 7/11/2025 10:01 PM, Lawrence D'Oliveiro wrote:   
   > On Fri, 11 Jul 2025 20:48:22 -0400, Arne Vajhøj wrote:   
   >> But the ORM makes it completely go away.   
   >   
   > And yet ..   
   >   
   >> ORM cannot read minds.   
   >   
   > Somehow it manages to be both: it can make the need for low-level SQL   
   > management go away, and yet it cannot figure out what language-native   
   > objects you want to replace it with.   
   >   
   >> Somehow the code need to tell the ORM what query to make.   
   >   
   > If you knew what query to make, you wouldn’t need the ORM.   
      
   You have misunderstood what an ORM provide.   
      
   You need to define your object model.   
      
   You need to specify logical what queries or updates you want to do.   
      
   What the ORM does (as the name implies!) is to handle the mapping   
   between the object model and the SQL statements.   
      
   You give it a query and it translate that into one or more SELECT   
   statements, read the result and stuff it into the object model.   
      
   You tell it to persist an object and it translate that into one   
   or more INSERT statements.   
      
   For complex object models having that stuff done automatically   
   save a ton of code.   
      
   It is cutting 50-75% of the database access code. And most business   
   applications has a lot of database access code.   
      
   It is not a silver bullet. There are a couple of caveats.   
      
   1) It only makes sense if you have an object model. If your code   
       operate on lists, maps/dictionaries and basic data types, then   
       there is no point in ORM.   
      
   2) There need to be at least one on the team with more than   
       basic skills in the ORM. Any developer can do the queries   
       and updates. But putting the annotations/attributes (or the   
       equivalent XML mapping for older ORM) on the domain classes   
       require deeper skills for any non-trivial case.   
      
   >> 20 years ago there were some pain points. But solution has been found   
   >> since then.   
   >   
   > I would like to see what some such “solution” might be, given you   
   haven’t   
   > offered one yet.   
   >   
   > How about tackling that web query-form example I posted elsewhere? The one   
   > with the long Python expression for packaging up all the fields with data   
   > that the user has entered into an appropriate SQL WHERE clause?   
      
   Query WHERE conditions are handled the same way in SQL and various   
   ORM query constructs.   
      
   That is part of the basic ORM stuff that has always been covered.   
      
   What has been added since is stuff like:   
   * ability for developers to explicit decide between one JOIN query   
      or 1+N queries - that is essential for optimization   
   * allowing certain non-object-oriented features, because in practice   
      database access code may need those   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)