Re: numRows in the oracle driver

From: Date: Mon, 10 Mar 2003 10:08:07 +0000
Subject: Re: numRows in the oracle driver
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-14164@lists.php.net to get a copy of this message
<smith@backendmedia.com> wrote : > Hi, > > I am having some trouble getting the numRows() method to work like I > want it to in the oracle driver. > > 1) Right now numRows() works the Metabase way of simply fetching all the > rows and then returning that number. > > 2) PEAR works by checking if the last query was the query for which > numRows() was called and then doing "SELECT COUNT(*) FROM > (".$this->last_query.")";. > > 1) Was the advantage of not sending off yet another query, which is > pretty ugly. But it makes the current while loops in fetchCol() and > fetchAll() fail because they rely on the fact that no other method has > messed around with the result set. I could fix that by specifying > fetchInto the exact row I want. This will result in mysql_data_seek > calls in the mysql driver. > > Anyways if all I want is all data and the numbers or rows that is no > problem as I can just do fetchCol|All and do a count on the array. But > if I first want to check the number of rows and then do a fetchAll() if > the number is what I want then I start to run into trouble. FYI: oracle > does not return the number of fetched rows because it starts to return > rows before it even finished finding all. So whatever the solution for > numRows it will go a bit against the spirit of the oracle driver anyways > (yes I know there is ocifetchstatement() but for several reasons that is > not a good alternative and certainly no "solution" to be problem) > > 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. Hi Lukas, There is no way to get the number of rows in an Oracle SELECT unless you make a count(*). Oracle users should be aware of that (and switch to a better, less expensive RDBMS...). You will always end up with an ugly hack. PEAR DB approach was not so bad, using a flag to tell whether to be portable or optimized IIRC. The only problem I see is if you issue a select query and get a result, then issue your numrows query, the result content might have been changed in between the two queries. I don't have a preference, I am just a bit afraid that solution 1) might take a lot of memory. Bertrand Mansion Mamasam

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