Re: PDO concerns

Wez Furlong wrote:

On Sun, 27 Feb 2005 17:44:38 -0600, Richard Thomas <lists@cyberlot.net> wrote:

First http://pecl.php.net/bugs/bug.php?id=3564 MySQL in php has always supported the use of rowCount() to return the number of results in a SELECT, to change this behaviour all of a sudden in PDO is going to cause some confusion to say the least. PDO as I knew it is not a "abstraction" layer but instead a common method of database access that is supposed to support all features of each database even if some features are not portable. Half the agruements for doing PDO to begin with that I have seen are claims that it is not a abstraction layer and not meant to be portable but can be at the programmers choice.. So why remove functionality that has always existed in MySQL access functions before?

This is a consequence of opting for high performance by default. For portability, you should issue a "SELECT COUNT()" query. For ease of use, simply use fetchAll(). The docs should state this clearly, as of right now any reasonable person would assume this should work by reading the docs, which suggests even more so that it was the original intent that this should work.

Next http://pecl.php.net/bugs/bug.php?id=3565 You can not do multiple querys without declaring your $return variable as null hence destorying the prior object. Now this one I may be off but no where have I ever seen a php method act in such a manner before at the very least this needs some very good doc's. What confuses me the most, this only affects the query statement not executes which is inconsistant.

Think about it for a minute; you created an object that holds open a cursor on the remote database. You need to destroy the object (by assigning it a null value) before you can open another cursor.

$stm = $db1->prepare('SELECT * FROM help_category LIMIT 1'); $stm->execute(); print_r($stm->fetch(PDO_FETCH_ASSOC)); $stm = NULL; $result = $db1->query('SELECT * FROM help_category LIMIT 1'); print_r($result->fetch(PDO_FETCH_ASSOC)); While it works it makes no sense, Why do 2 prepares in a row work and not 2 querys? Because a prepare properly closes and previously open cursors, while a query clearly does not. If this is the true intent it should be properly documented, If "cleanup" is needed why not have a close method like mysqli does? If you are not going to provide the option to use non-buffered OR buffered querys ( like mysqli_use_result and store_result in mysqli ) it needs to be documented clearly so people understand whats going on. This is by programmer choice, not by design or requirement as mysqli clearly documents and shows. This is just my thought and input I don't contribute directly to php other then bug reports here and there so maybe im just way off here and I am sure the docs will be cleared up prior to 5.1 being released, but one of the largest complaints you will find out there when it comes to php is how inconsistent it is when it comes to function naming, input order and such. Performance is nice but it should not be an excuse to break the flow of how things have always worked in the past. If you where to ask 100 php programmers what the following mysql should produce EVEN if they feel its a poor and improper method they would still assume it would return number of rows returned. $result2 = $db2->query('SELECT * FROM songs'); echo $result2->rowCount()."\n";

--Wez.

-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.5.0 - Release Date: 2/25/2005