Re: numRows()

"James L. Pine" wrote: > > the oci8, oracle, and ibase modules don't have functions for numrows. the > odbc module may or may not return the number of rows in the result set, > depending on the type of database to which it is connecting. > > I'd go against adding numrows to the db layer. simply returning > not_implemented isn't that good of a thing, as (when it's there) it's a > very very commonly used function... this is a sure trap for lack of > portability, which I'd like to view as a main goal for any db abstraction > layer. yes, you can have a nice function matrix that tells you what > functions not to use if you'd like to be able to switch to and from > databases later on, but that's kind of a cop out. and yes, I know that > sql isn't ever as portable as it ought to be, with nonstandard functions > and rogues like mysql that don't even have subqueries... but it's not > practical to have a db layer filter out non-generic sql, while it is (at > least to me) practical to discourage non-generic functions. > > there will probably never be a wonderfully simple and efficient way of > doing numrows in the databases that don't support it through native php > functions. cycling through and counting rows in the result set is not > exactly optimal, and doing something like 'select count, cursor($query) > from (select count(*) count from ($query))' and sorting things out after > every select query is a bit more painful that it ought to be. > > if it's decided by those more important than me that numrows should go in, > I'd probably angle for some config option to pick which non-efficient > numrows emulation method to use. > > of course, if I'm totally off and missing some essential ingredient to > understanding, please clue me in. I have never really had the need for numRows myself (usually you can get around somehow anyway), and I would not mind not supporting it, exactly because it is hard to emulate. - Stig