PDO newbie experience - unbuffered query

My PHP5 and PDO (PHP Data Objects) experience is very young (to be exact: one day), but I have already learned an important lesson, which is rather a mysql lesson, than PDO, I guess.

PDO default is unbuffered query
I had the simple code:

$dbh = new PDO(’mysql:host=localhost;dbname=test’, ‘root’, ”);
$dbh->prepare(’SELECT * FROM test WHERE test_id=?’);
$dbh->execute(array(1));
$dbh->fetchColumn(0);
$dbh->prepare(’SELECT * FROM test1 WHERE test1_id=?’);
$dbh->execute(array(2));

It always gave me a “Call to a member function execute() on a non-object” in the line of the last execute(). I was really speechless. I even tried to create a new PDO object every time, that seg-faulted on me. It wasn’t the right thing to do anyway, so that was ok.
With Johann’s help we found out that the unbuffered query is the problem. I didn’t retreive the complete result set (I only do a fetchColumn()), so there is still an open result set on the server. And a new execute() is awry. Calling a fetchAll() after the fetchColumn() helps, but is not what you want to do. The solution is to use buffered queries, create the new PDO object with the attribute PDO::MYSQL_ATTR_USE_BUFFERED_QUERY set to true, like so:

$dbh = new PDO(’mysql:host=localhost;dbname=test’, ‘root’, ”
,array(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => true));

Ilia already mentioned this problem last year. Anyway it still seems to be a point that needs to be stated clearer in the docs. I am happy I learned something. That’s not bad for one day PHP5 and PDO.

Why not Python?
If you followed this blog and are wondering how come that I am doing PHP again, well it is the simplest to get running. I would love to do it in Python, but getting set and started simply takes much more time, and I just want to get a prototype out the door. I am also much more familiar using PHP and my latest experience with the EXIF stuff for Python doesn’t make me very optimistic, that Python is easy enough to use for all the web tasks I expect to do.
I am sure that if I did about a month of this stuff in Python I will have understood it all too, but I don’t have this time now, unfortunately. But at least I have the plan to redo it all in Python (btw. I have many plans).

3 Comments »

  1. Florian said,

    April 5, 2006 at 8:15 am

    Hm, funny I find PHP incredibly much harder to use then say plain mod_python + cheetah/kid or Turbogears.

    PHP makes me go trough all that cruft code I don’t really want to concern myself with, and it doesn’t come with great templating out of the box and so on and so on.

    On top of that, I’m quite used to quickly move forward in abstracting logic of my app, factoring out behavior to classes, common-base classes, factories etc. that kind of all sucks with PHP because their OO sucks bad, but you know that.

  2. Wolfram said,

    April 5, 2006 at 9:22 am

    I think it is simply because I was doing PHP already for many years and learned Python just last year, and there I was only using it for a non-web project. Actually the only experience of Python with web I got by investigating the trac source and playing a little with it. But I guess, since they handle all of the CGI themselves, this is not the easiest and, what I am most interested in, fastest way to do it.
    I would be interested to do things in PHP and Python in parallel, with some experienced Python developer, in order to directly compare the two on some standard tasks. Someone interested? And of course so I can learn how to do the web stuff in Python.

  3. Olivier said,

    October 5, 2009 at 2:31 am

    I know my comment is very late… anyway, there is a very good templating system with PHP, and it’s XSLT.
    Much better and much easier to use than any other existing templating system.
    And it’s portable too, so if someday you want to use another language, your templates are still there.

RSS feed for comments on this post · TrackBack URL

Leave a Comment