Re: DB oci8 numRows() and portability
| From: | Lukas Smith | Date: | Sat, 17 Jan 2004 19:09:44 +0000 |
| Subject: | Re: DB oci8 numRows() and portability | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-25121@lists.php.net to get a copy of this message | ||
Daniel Convissor wrote:
On Sat, Jan 17, 2004 at 10:01:19AM +0100, Lukas Smith wrote:Then they need to enable portability mode. So it goes.The reasons is that someone writes an app that is supposed to work with multiple backends but they have their own custom fall back if numRows fails. For example they could then just fetch the entire result set into a buffer etc.And the likelyhood of that is??? It's far more likely that someone new to the package (or trying to port something to Oracle) will try to use the method without having portability turned on needlessly get an error.
Even if someone has done what you said, their code already has the ability to handle the result of the method when it actually returns the number of rows, so their program would continue on the direct course rather than their own convoluted workaround. Either way, they wind up in the same place.No. The portability does some magic on the last query and then execute that query. This is obviously not what the mysql driver does where you get this information for "free" as mysql buffers the entire result set anyways. Anyways Daniel I really appreciate your efforts but you have to accept that breaking BC is breaking BC even if this is how you would write it if you would start over. regards, Lukas