Re: numRows(), out of order row fetching and stuff?

"Hans Lellelid" <hans@appliedsec.com> wrote in message news:20030721133907.4D2D04A61E@punisher.appliedsec.com... > > > | Is it ok to drop numRows()? > > In the apps that I've written with MDB, I don't think I've ever needed to > use numRows(). I was going to say that numRows() is important when doing > pagination, but even in that case, my "Search" classes just rebuild a > COUNT(*) version of the query to use for calculating total result set > length. In MySQL 4, there's another interesting way of implementing this, without the problems with DISCTINCT and other selects. Actually I use this method in one of my pagination/sorting classes. The thing is to put SQL_CALC_FOUND_ROWS clause in the SELECT query and then execute SELECT FOUND_ROWS(), which returns the number of rows in the previous select (which can be cut with LIMIT). http://www.mysql.com/doc/en/SELECT.html "SQL_CALC_FOUND_ROWS (version 4.0.0 and up) tells MySQL to calculate how many rows there would be in the result set, disregarding any LIMIT clause. The number of rows can then be retrieved with SELECT FOUND_ROWS(). See section 6.3.6.2 Miscellaneous Functions. Please note that in versions prior to 4.1.0 this does not work with LIMIT 0, which is optimised to return instantly (resulting in a row count of 0). See section 5.2.9 How MySQL Optimises LIMIT. " In my opinion, we should have a switch clause here, to use the optimal code for each database. Abstraction is abstraction, but when the users can do things faster with their own specific classes, there's no reason for them to use PEAR. Kouber Saparev