From: arne@vajhoej.dk   
      
   On 7/29/2025 7:07 PM, Lawrence D'Oliveiro wrote:   
   > On Tue, 29 Jul 2025 09:39:51 -0400, Arne Vajhøj wrote:   
   >   
   >> On 7/29/2025 12:25 AM, Lawrence D'Oliveiro wrote:   
   >>>   
   >>> On Mon, 28 Jul 2025 22:36:59 -0400, Arne Vajhøj wrote:   
   >>>>   
   >>>> JPQL example (ORM specific query language):   
   >>>>   
   >>>> List res = em.createQuery("SELECT o FROM T1 AS o WHERE o.f > 0",   
   >>>> T1.class).getResultList();   
   >>>   
   >>> That seems like a really dumb idea. You see my point about having their   
   >>> own query language does nothing to simplify the code.   
   >>   
   >> Again: the benefit is not in the query but in the fact that it stuff the   
   >> query result into the object model without any application code.   
   >   
   > So why does it have its own extra mechanism for formulating the query,   
   > then? You yourself are admitting there is no benefit in that. Yet here you   
   > are, having to go through that same extra layer of mechanism.   
      
   It is not an extra layer. It is an alternative layer.   
      
   As I said then there are 3 options:   
   * ORM specific QL   
   * fluent API   
   * SQL   
      
   I believe the arguments goes like:   
   * ORM specific QL - similar to SQL so easy to learn   
      but fit better with the object approach than SQL   
   * fluent API - more type safe than a string with a QL   
   * SQL - everybody already knows SQL so picking that avoid   
      learning a new way   
      
   Different ORM chose differently.   
      
   If I were to make a guess then I would say usage is like   
   50% - 40% - 10%.   
      
   (note that some ORM support more than one option)   
      
   If you were to create your own ORM, then feel free to   
   make it use SQL.   
      
   It does not really impact the application code that much, because   
   no matter which option then the same query need to be expressed.   
      
   >>> Is there a version that returns an iterator? Can be more   
   >>> memory-efficient for dealing with lots of returned records.   
   >>   
   >> Usually there are.   
   >>   
   >> But it is a rare requirement when using object models.   
   >   
   > On the contrary, I use it a lot. Maybe the problem is that object models   
   > make the idea hard to use.   
      
   Transactional/operation code use an object model but don't work   
   on huge data. If the data is huge, then you paginate.   
      
   Reporting/analytical/data transfer code  often work on huge data, but   
   you don't use an object model with that.   
      
   >> .NET has one of the easiest ways to do it.   
   >>   
   >> List res = db.T1.Where(o => o.F > 0).ToList();   
   >> foreach(T1 o in res)   
   >>   
   >> will materialize all rows in memory and then iterate over it, but:   
   >>   
   >> foreach(T1 o in db.T1.Where(o => o.F > 0))   
   >>   
   >> will iterate directly.   
   >   
   > Can you explicitly call a “next()” method on an iterator object to   
   > retrieve each record in turn?   
      
   If your religious beliefs do not allow you to use foreach loop, then:   
      
   foreach(T1 o in whatever)   
   {   
        ...   
   }   
      
   can be done as:   
      
   IEnumerator en = whatever.GetEnumerator();   
   while(en.MoveNext())   
   {   
        T1 o = en.Current;   
        ...   
   }   
      
   But I really don't see any reason to do that.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)