From: ldo@nz.invalid   
      
   On Wed, 16 Jul 2025 20:26:46 -0400, Arne Vajhøj wrote:   
      
   > 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.   
      
   So, if I leave out the ORM, then I don’t need to “define” an “object   
   model” that it can handle, and just go straight to the queries/updates.   
   Sounds like less work, to me.   
      
   > 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.   
      
   I’ve seen ORM calls corresponding to more complex queries, like joins.   
   Basically you are just expressing the join in a separate language of equal   
   complexity, with no effort saved that I could see.   
      
   > 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 just replacing it with a lot of ORM code.   
      
   > And most business applications has a lot of database access code.   
      
   I maintain one sizeable application for a client that was written in PHP   
   (by a previous developer). They tried to wrap table information in custom   
   classes representing things like employees, work entries, customer   
   companies and company contacts. The code was just a convoluted mess,   
   adding complexity instead of removing it. In every page representing some   
   database query/update function that I needed to make major changes to, I   
   saved code by getting rid of use of these classes and substituting the   
   queries and handling the results directly.   
      
   > 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.   
      
   But surely just about all code fits that description.   
      
   > 2) There need to be at least one on the team with more than   
   >     basic skills in the ORM.   
      
   And if you have different apps written in different languages, all   
   accessing a common database (a very common situation), you need someone   
   with ORM skills in every language.   
      
   >> 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.   
      
   Show us.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)