Jeremy Cook has put together a quick guide for something that can be tricky when using PDO in PHP - handling binary data in the return from your queries.

I like the fact that if I needed to use MS SQL Server, Oracle or any of the other big RDBMS's I could use the same PDO syntax to access them rather than learning a new database access library. However, there do seem to be some bugs in PDO according to what I've read on the web. While I haven't encountered most of them and can't comment on them I'd like to write about one that I ran into the other day and how I worked around it.

He was storing images in the database and pushing the information into the database was working fine. When he tried to pull the contents back out, however, the information wasn't being handled correctly (according to the example in the PHP manual) because of a differing return value for the fetch call - sometimes it's a string but, in this case, it's binary data so it needs to just be passed on through.

Lukas Smith has formally kicked off a restart of the PDO (PHP Data Objects) abstraction layer, trying to get interest back into this part of the PHP project and get developers back into patching and creating more features on it as a whole.

The problem with PDO's current state is that there are just so many bugs open that it seems like a maintain. Plus the original creator(s) are busy with other things, which means the learning curve is steep. Which makes it all the more important that we both have new guys as well as experienced core developers on this. I think for too long we have waited for RDBMS vendors to bring in the momentum. However since we decided to not play according to the "rules" they have proposed, its obviously our job and not theirs.

He asks that all that are interested in closing out those bugs and really getting the development of PDO back on track sign up for the mailing list and check out the brainstorming page on the PHP wiki on general ideas and thoughts on where the project should be headed.

Since sometimes you just don't want all of the results of a query back at once, Rob Young has posted a solution of his own using the Iterators included with PHP as a part of the SPL. His solution is to wrap it in a ChunkedQueryIterator that handles the work behind the scenes.

When executing large queries it's usually best not to load the whole result set in one go. Memory isn't infinite and PHP isn't renowned for handling it very well. So the obvious answer is to chunk the large query in to lots of smaller queries. [...] We want something to which we can just provide a PDO object, an SQL query and the chunk size. We should then be able to iterate over the resulting object as though it were a single result set.

He includes two code snippets of it in action, but asks the question of his readers - "How do you handle large database queries?" - to get some feedback on other alternatives.

Brandon Savage has posted the next part in his "Beginner Pattern" series sharing some of the basics of PHP with his readers. In this new article he looks at the PDO functionality and how it can be used to connect to and read from a MySQL database.

PDO offers a number of enhancements and improvements over the various database libraries (e.g. mysql_*, mysqli_*, pg_*), the biggest one being consistency. Still, the high level of code that involves direct use of the various database libraries means that PDO still isn't as widely accepted as it should be. This primer will show the various uses of PDO, and outline some of the benefits.

He gives two bits of example code - one showing a transaction and the other a normal MySQL connection without any kind transaction wrapper around it as an example of "the old way" to do things.

Hasin Hayder has posted about a method for turning a normal WordPress installation into a muilt-user blogging system backed by an SQLite database.

Wordpress is one of the very popular blogging platform which is not only free but also released as a open source project. officially wordpress runs only on mysql. so if you want to run it with SQLite, you will not find any official support for that.

He has five steps in his process for converting the backend away from MySQL and over to SQLite:

• Add a wildcard to your DNS setup for the hostname you're using
• Install WordPress
• Install PDO for WordPress
• Create the directory where the user databases will exist
• Change the database configuration to write to a SQLite database file based on the hostname (which is what the DNS wildcard makes easier)

In a recent post to his blog, Davey Shafik looks at solving something that has "always bugged him about using prepared statements" - getting the actual query it used back out.

Today, a friend asking me if it was possible to get a prepared statement back from PDO with the values placeholders replaced, finally caught me in a moment where I could do something about it. I wrote a thin PDO wrapper class that will [imperfectly, I'm sure] return the completed query.

His class (complete code included in the post) includes a getSQL() method that hands you back the results of your bound parameter query as a string. A few examples of its use are also included.

Fabien Potencier has a new post about a strange and hard to track down bug he was experiencing with serializing a symfony form - it was throwing a PDO exception.

This exception is thrown by PDO because PDO instances are not serializable for good reasons. But it is weird because the sfForm class does not depend on PDO. How is it possible?

After some poking around, he noticed that this was only an issue for those with sessions stored in the database (that's where the PDO comes in). The problem came with the validation error class - it extends the exception class and, because of how the error handling serializes the exception, it tries to serialize the PDO connection that's in the stack trace too.

His solution is to use a Serializable interface to define exactly what you want serialized and passed back out as the error to the rest of your script.

On the PHP::Impact blog Federico points out a new feature/update that the Propel team has made to help with performance - a change from Creole to the based PDO layer that PHP includes.

This change has a number of implications, particularly for those who are executing SQL directly. PDO's API is loosely similar to Creole's, so this change shouldn't require any major re-architecture.

New features that come along with this move you might have to upgrade for include the newer DSN format for build/runtime properties, the removal of the mysqli adapter, SPL autoload integration and a few API changes you'll have to look out for. You can find out more information on the Symfony framework's support for these changes on the sfPropelPlugin and DbFinderPlugin pages.

The Internet Super Hero blog has posted a series of updates on the state of the PDO setup for the MySQL native driver:

• PDO_MYSQLND: R[a¦u]mbling and a breeze of progress
• PDO_MYSQLND: Calling Stored Procedures works fine with mysqlnd
• PDO: Learn how the PDO SQL parser causes bug reports
• PDO_MYSQLND: Mighty multiple-queries and PDOStatement::nextRowset()
• PDO_MYSQLND: Monday morning murders

You can find out more about the project from its page on the MySQL website.

Kae Verens has posted a review of another of Packt Publishing's PHP-related offerings, "Learning PHP Data Objects" by Dennis Popel (published in Aug 2007).

Learning PHP Data Objects, by Dennis Popel, is an introduction to PDO, which walks through the building of a believable test example - a library manager for your home library. [...] I really couldn't find very much about this book that I didn't like. Ignoring the appendices, the book is 154 pages purely devoted to teaching PDO through examples, including error handling, working with BLOBs, even the creation of the M in MVC (Models).

The review mentions Models, Active Record and how the book creates a Library manager application that includes the use of prepared statements and transactions.