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

> From: Manuel Lemos [mailto:mlemos@acm.org] > Sent: Tuesday, March 11, 2003 7:17 AM > To: Jason Lotito > Cc: pear-dev@lists.php.net; metabase-dev@yahoogroups.com > Subject: Re: [PEAR-DEV] Re: [metabase-dev] numRows in the oracle driver > > He's not concerned about making it different from Metabase. He is > > concerned about making it good. I am facing this same problem dealing > > The way I see it, Lukas is trying to make it work differently in hope to > improve the use of a function that is being explicitly discouraged in > the Metabase documentation. Users that read the documentation are aware > of the cost of using the function, so why bother changing what is not > broken and what does not need to be improved because its use is > discouraged? I know it is discouraged in the Metabase docs. I was just trying to get a better understanding of this issue, especially the memory implications. I am not very much familiar with the php source and how fetched rows and their relationship memorywise in the result arrays once they are fetched. If it is infact true that they will reference the same memory space we have less than an issue. However we also need to keep in mind that we have the type conversion, which will mean that atleast some values will not be the same and therefore the reference counting will not work. > > > with the Eclipse library right now. Trying to integrated an Oracle > > class into it, and putting all the row data into memory doesn't seem to > > be efficient. > > > > COUNT(*) is much more efficient, especially considering how it works. > > As I explained in another message, doing two selects is not the same > thing unless you can guarantee that between the two selects the data in > the result set did not change. You can only guarantee that, > encapsulating the selects in a transaction, which is a worse idea. Exactly. That is why I also did not like that solution either. But I am wondering why should we even allow people to fetch rows out of order? Couldn't we then get rid of some memory usage? That will of course not be a solution for the numRows() problem. There we really can't do much beyond what you have done with Metabase already. 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. Regards, Lukas