RE: [PEAR-DEV] Re: [metabase-dev] numRows in the oracle driver

> -----Original Message----- > From: Manuel Lemos [mailto:mlemos@acm.org] > Sent: Tuesday, March 11, 2003 2:12 PM > To: metabase-dev@yahoogroups.com > Cc: 'Jason Lotito'; pear-dev@lists.php.net > Subject: Re: [PEAR-DEV] Re: [metabase-dev] numRows in the oracle driver > What you need to know is that when the API does result set buffering > like MySQL does, the whole result set is retrieved to some memory space > that has nothing to do with PHP variables memory space. So, you always > have a memory issue when buffering is used. So, this is not even a issue > just of Oracle driver. Ok. > > > But I am wondering why should we even allow people to fetch rows out of > > Some people want to traverse the result set more than once. For small > result sets that is not a great problem, so I do not see much point in > disallowing that. But that creates memory issues for large result sets. As you point out these already exist for mysql. But why introduce these memory issues into the oracle driver? If people want to traverse the result set more than once they can just do just that by using one of the bulk fetching methods. Then they have the data in an array with which they can do whatever they want. > > One possible thing would be to introduce a switch to always do the query > > that is done in PEAR DB's numRows() on every select and store that > > value. But I am not sure that this is really a good idea either. > > I do not like that solution because you are forcing a mandatory overhead > to provide something that may not be needed. I prefer that you buffer > the rows or not depeding on a hint passed by the programmer. When not > buffering, NumberOfRows() would not be functional. Ah, you misunderstood me. I also want to make it possible for the programmer to set such a hint. Probably introducing a new option. So then we would buffer the result set if users say they want to and in the default not buffer. I just got a mail from Lorenzo who is working on an interbase driver. And interbase works much the same way as oracle there. So this decision undoubtly goes beyond "just" oracle. Regards, Lukas