1. PDO::firstImpressions()

    My pet project du jour has to do with PHP, commits and RSS. I'll talk about it here when it's ready, but in the mean time, here's a teaser.

    Part of what I'm doing is putting commit data into a database. Since I'm re-architecting my database schema and access methods, I figured that this would be the perfect opportunity to try PDO.

    (UPDATED below)

    Here are my first impressions.

    Let me say, first, that I think PDO has a LOT of potential. Even the work that has already been completed is wonderful, and it will push PHP forward into even heavier usage. I used to write CFML (please don't hold it against me), and one of the key benefits of Coldfusion was uniform database connectivity.

    Additionally, I've never been able to do cool things like use prepared queries in MySQL before, and while it's not technically possible to actually do this in (at least in the version I run -- see below), PDO's emulation layer is an incredible idea that I'm going to have a hard time living without at work (where we're still on PHP 4.. at least for the next couple months).

    In short: PDO is great. It will become an indispensible part of the PHP core distribution. Kudos to all involved.

    I'm running PHP 5.0.3 with php checked out from PECL CVS. The database I maintain on that box is MySQL, so I grabbed both PDO and PDO_MYSQL. I used the phpize method, and then stuck the extension=*.so directives in my php.ini.

    So far so good.

    The version of MySQL I have installed is that which is part of Debian stable: MySQL v3.23.

    Here's where the going got rough. I was (apparently) the first to try PDO on this version of MySQL. The first time I constructed a PDO object, an exception was thrown, which lead to PECL bug #3470.

    Wez has been not only instrumental in creating PDO, but also extremely helpful in diagnosing/confirming (or bogussing (-: ) the problems I've had.

    So, I commented out the offending line that caused the constructor to fail (and I see that this has been fixed in CVS, but I'm unable to test, currently (again, see below)), and continued working on my project.

    The prepared statements are REALLY nice. I can't say I've ever had such an enjoyable experience with MySQL access (except for DBDO).

    I ran into three more issues. The last of which leaves me unable to use PDO in its current state (in CVS).

    All in all, PDO is going to be great. Hopefully in time for PHP 5.1 (tentatively March 1st). I'd even suggest postponing 5.1 if PDO still has major bugs.

    PDO_MYSQL isn't what I'd consider production/release quality, currently, but these bugs seem like they'll be easily overcome. I think it needs more testers -- what I've found broken, I've reported, but some of this stuff I was quite surprised to find that I'm the first to discover the flaw.

    It seems that with PDO, MySQL was largely overlooked (the absence of a PDO_MYSQLI attests to this), and I'm certainly not one to extoll the virtues of MySQL, many PHP users know nothing else, and we'd be well-advised to make PDO_MYSQL as smooth as possible.

    ... anxiously awaiting a stable PDO and 5.1. Again, great work, guys.

    UPDATE: Following Wez' suggestion in bug #3549, (but also additionally actually removing the previously-instlaled pdo*.so files), I was able to get PDO working in its current state (from CVS).

    1 Response

    Feed for this Entry
    • Thanks for the positive press, Sean. Yes, I'm a bit dissappointed by the level of feedback; based on the handful of bug reports that have been submitted, only about 4 or 5 people are really giving it any serious testing. We're relying on you guys (and gals) to try using it in the ways that you use databases, simply because you do things differently from us and will pick up problems that we wouldn't otherwise see.

      Regarding mysqli, I believe that Hartmut is going to roll the newer bind support that everyone associates with mysqli into the existing PDO_MYSQL package. There won't be a PDO_MYSQLI, simply because it is not needed--mysqli only exists because maintaining ext/mysql has gotten too difficult, and it would be twice the amount of work to retro-fit the newer mysql client APIs than to start afresh--starting afresh won Georg's vote.