Re: PDO concerns

Thanks for the details I understand PDO is new, I guess part of my problem is I basically learned PHP from www.php.net and the great online docs in my opinion are one of the reasons php is where it is today so sometimes I get frustrated when things don't work the way the docs suggest they should. There is something diffrent however between a PDO::query and a PDO::prepare and execute, Because 2 prepare/executes in a row work without having to declare anything NULL, Run the code there is no confusion on my part in how this works, Well there was confusion in that I assumed that since 2 prepare/executes do work without declaring the stm null the fact that 2 querys didn't had to be a bug in my mind. $dsn = 'mysql:dbname=mysql;host=localhost'; $db1 = new PDO($dsn, 'root', ''); $db1->setAttribute(PDO_ATTR_ERRMODE, PDO_ERRMODE_EXCEPTION);

$stm = $db1->prepare('SELECT * FROM help_category LIMIT 1'); $stm->execute(); print_r($stm->fetch(PDO_FETCH_ASSOC));

$stm = $db1->prepare('SELECT * FROM help_category LIMIT 1'); $stm->execute(); print_r($stm->fetch(PDO_FETCH_ASSOC)); Shouldn't work but does? Richard Thomas - CEO Cyberlot Technologies Group Inc. 507.398.4124 - Voice Wez Furlong wrote:

On Sun, 27 Feb 2005 20:30:42 -0600, Richard Thomas <lists@cyberlot.net> wrote:

Next http://pecl.php.net/bugs/bug.php?id=3565

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

I think you're confused, because PDO::query() is identical to calling PDO::prepare() and PDOStatement::execute(); both return you a statement object that (for almost all drivers) must be destroyed before you can execute additional queries.

If this is the true intent it should be properly documented, If "cleanup" is needed why not have a close method like mysqli does?

It's called a destructor, and you'll find that assigning the mysqli resource a null value has the same effect. This is the same behaviour you'll find with all PHP resources and objects since their conception. close methods are just fluff, and present something of a chicken-and-egg problem for objects (for similar reasons, we don't have a "delete" statement in PHP).

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.

Just use PDO::fetchAll().

Performance is nice but it should not be an excuse to break the flow of how things have always worked in the past.

It's not an excuse, and performance isn't even the primary reason; consistency is. We default to forward-only rowsets because they are a common base. PDO isn't about making people feel cozy about their mysql based PHP scripts. The fact of the matter is that people coding for traditional ext/mysql are isolating themselves from the real world of other databases. PDO is an opportunity for those people to elevate themselves. The bottom line is that PDO is new. It is not ext/mysql, and we're not breaking how things are--it's just different.

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";

We can easily fix this misconception by providing a good example on the rowCount() manual page. --Wez.