$db = new PDO('mysql:host=localhost;dbname=example', 'example', 'secret');
 
$tags = $db->prepare("
    SELECT 
        * 
    FROM 
        bookmark_tags, tags 
    WHERE 
        bookmark_tags.bookmark_id = ? AND 
        tags.id = bookmark_tags.tag_id 
    ORDER BY 
        tags.name");
 
$bookmarks = $db->prepare("SELECT * FROM bookmarks ORDER BY Title");
$bookmarks->execute();
while ($bookmark = $bookmarks->fetchObject()) {
    echo "<li><a href='{$bookmark->url}'>{$bookmark->title}</a> ";
    
    $tags->execute(array($bookmark->id));
    while ($tag = $tags->fetchObject()) {
        echo $tag->name, " ";
    }
 
    echo "</li>\n";
}
echo "\n";
 

Unfortunately, this didn’t work and it took me a few minutes to figure out why. Actually, I still don’t know exactly why it doesn’t work, but I did find a way to make it work: by using two separate connections, one for each prepared statement. It doesn’t seem like you can have two active statements at the same time on the same connection. I find this hard to believe, so I’m probably doing something wrong.

The other thing I didn’t care for with this PDO code is the non-standard method of iteration with the while loop. Well, the while loop is perfectly standard if you are coming from the PHP 4 style functional DB APIs. However, it doesn’t seem to fit in with the PHP 5 Iterator and foreach integration. PDO doesn’t seem to provide a distinct result set object, or a method of iterating over a result set using the standard PHP Iterator interface.

Now, I can understand why this may be the case. The PDO interface seems to be designed to bind to php variables. Thats not going to work with the Iterator interface. However, I am not using that mode and don’t want to use that mode. It would be nice to be able to acquire an iterator for an example of use such as the one above without having to use fetchAll and ArrayIterator.

Using the Iterator style makes it easier for me to decouple my code from the data source and makes it easier to write test cases for that code.

I was a little bit disappointed. So I moved on to MDB2 with the same code …

 
require_once 'MDB2.php';
require_once 'MDB2/iterator.php';
 
$db = MDB2::connect("mysql://example:secret@localhost/example");
 
$tagLookup = $db->prepare("
    SELECT 
        * 
    FROM 
        bookmark_tags, tags 
    WHERE 
        bookmark_tags.bookmark_id = ? AND 
        tags.id = bookmark_tags.tag_id 
    ORDER BY 
        tags.name");
 
$bookmarkFinder = $db->prepare("SELECT * FROM bookmarks ORDER BY Title");
$bookmarks = new MDB2_Iterator($bookmarkFinder->execute(), MDB2_FETCHMODE_OBJECT);
    
echo "<ul>\n";
foreach($bookmarks as $bookmark) {
    echo "<li><a href='{$bookmark->url}'>{$bookmark->title}</a> ";
 
    $tags = new MDB2_Iterator($tagLookup->execute($bookmark->id), MDB2_FETCHMODE_OBJECT);
    foreach($tags as $tag) {
        echo $tag->name, " ";
    }
 
    echo "</li>\n";
}
echo "</ul>\n";
 

I have about the same level of non-experience with MDB2 as with PDO, but my code worked perfectly on the first try and allowed me to use Iterator, which will be helpful to the next stage of my test.

I was a bit impressed. I’ll see how well it handles the next stage of what I want to do.

(And yes, I know there is no error checking in the above code.)

I really don’t know much about PDO, i haven’t used it yet. Most of what I know comes from:
Wez Furlong’s first steps with PDO examples
Wez’s Oracle PDO Article
John Lim’s discussion of adodb and PDO
A sitepoint thread on PDO
I haven’t seen any API type docs yet. I did download an older version of the PECL code and skim through it.

Alan has some interesting things to say. I have to agree with him on using libgda as a back end. Using a more mature, existing, debugged code base seems very reasonable to me. Could libgda be used as the PDO back end while retaining the PDO front end API?

When I first looked at PDO, the parameter binding is one of the things that really jumped out at me. It reminded me of register globals, a technique that didn’t necessarily turn out well and was painful to back out of. Now that Alan says it, this technique is a bit more reminiscent of C than PHP. As i understand its an optional way to use PDO. A way that I would not use.

Wez comments:

- copying C: I agree that bound parameters can lead to magic code. There are two things to keep in mind: a good coding style (with comments) is the best remedy for code that might be considered magic.

I have to strongly disagree on the coding style point. Salting magic code with comments does not make it palatable. The solution is to remove the magic.

I am not familiar enough with PDO to understand the iterator argument. None of the examples I have seen actually use iterators.

What I would like to see out of a basic OO DB API in PHP is better support for translating the database record into an object. For example, the fetch(PDO_FETCH_OBJ) method returns an anonymous object. I would like a way for this method to construct an object of a particular class along with an initialization protocol such as unserialize has with objects.

I do think that PDO should be a part of core PHP, but perhaps one with a more mature libgda backend and a more evolved PHP front end API, influenced by Alan’s feedback and DBDO efforts.

I have noticed that sometimes the API design in PHP tends to simply wrap underlying 3rd party C libraries, even when that design doesn’t make the most sense in PHP. (for example the PHP wrapping of expat) PDO is a more of an attempt to design a PHP oriented API and then work the 3rd party libraries into the common design. To me, this is a step forward. However, the PDO API probably needs to go through a few iterations as Alan suggests before being frozen into core PHP.