Re: numRows in the oracle driver
| From: | Bertrand Mansion | 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