Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.os.vms    |    DEC's VAX* line of computers & VMS.    |    264,096 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 262,923 of 264,096    |
|    =?UTF-8?Q?Arne_Vajh=C3=B8j?= to Lawrence D'Oliveiro    |
|    Re: VMS x86-64 database server    |
|    31 Jul 25 15:16:05    |
   
   From: arne@vajhoej.dk   
      
   On 7/29/2025 10:41 PM, Lawrence D'Oliveiro wrote:   
   > On Tue, 29 Jul 2025 20:56:18 -0400, Arne Vajhøj wrote:   
   >> On 7/29/2025 7:07 PM, Lawrence D'Oliveiro wrote:   
   >>> 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.   
   >   
   > How would you redo your example to not use that layer?   
      
   If you don't like the QL/QAPI of an ORM, then you pick another ORM.   
      
   >> Transactional/operation code use an object model but don't work on huge   
   >> data. If the data is huge, then you paginate.   
   >   
   > So ORMs are not scalable?   
      
   It is not a technology limitation.   
      
   It is a functional requirement.   
      
   Nobody want to go to a list page and have it take 30 minutes to   
   load a billion rows or make a web service call and get a 1 TB response   
   back with a billion rows.   
      
   >> If your religious beliefs do not allow you to use foreach loop, then:   
   >>   
   >> foreach(T1 o in whatever)   
   >> {   
   >> ...   
   >> }   
   >>   
   >> can be done as:   
   >>   
   >> IEnumerator
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca