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

Hello, On 03/11/2003 04:58 AM, Lukas Smith wrote:

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.

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.

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.

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.

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. -- Regards, Manuel Lemos