Re: numRows()

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. --jlp