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

From: Date: Tue, 11 Mar 2003 06:17:17 +0000
Subject: Re: Re: [metabase-dev] numRows in the oracle driver
References: 1 2 3  Groups: php.pear.dev php.pear.dev 
Request: Send a blank email to pear-dev+get-14184@lists.php.net to get a copy of this message
Hello, On 03/10/2003 02:40 AM, Jason Lotito wrote:
2) Gets rid of the issues if 1) but via an ugly hack. Anyone who cares about the oracle driver should speak up now or I
will
make a decision alone.
Why you are so concerned in making it differently than Metabase? Is it some kind of limitation of PEAR-DB API that prevents you to map
Metabase
behaviour?
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?
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. Maybe for specific applications you can make the assumption that the data will not change between two selects but the database abstraction layer itself can not make that assumption for you because it does not have that information.
Personally, I would like to here the pro's and con's of either side (and not just a "This is the right way because I say so"). Would help me as well.
You are jumping to wrong conclusions and turning a purely technical issue into a personal issue. Nobody imposed their points of view. For the technical reasons that I have explained, doing two selects is not a solution at all that can be embedded in the database abstraction layer. The solution that I recommend is to not use NumberOfRows at all. You can do a select count() if necessary with the precautions to avoid the problem that the row count may change between two selects, but that should be done by your application and not the database abstraction layer. That is the solution that I used in this class for displaying query results in HTML tables split between pages of a limited number of rows. http://www.phpclasses.org/querytabledisplay -- Regards, Manuel Lemos

« previous php.pear.dev (#14184) next »