Larry Garfield (Crell) and I are currently working on a PDO database layer -- which does a lot more than merely introducing PDO to Drupal. In itself, adding PDO to Drupal is benefical because instead of our Drupal-specific placeholders we will be able to use a standardized ? placeholder. In addition, you can use :nid style placeholders and pass in an associated array of values.

I am not in love with OOP but I must admit that here OOP seems the best solution because this way we can support multiple database types and at the same time remain speedy. During the D6 cycle Adrian tried to write this with the current database layer, using variable function calls and that is slow. Inherited method calls are OK. Also, PDO itself is OOP based. We are going to supply factory functions, though -- we expect that noone in Drupal will ever need to write a new Database... something.

As I outlined earlier we have worked on a query builder which works with chainable methods. Also, we are providing db_insert and db_update factory functions which take a table name and an array of fields and values and return an InsertQuery or UpdateQuery object. Databases that require special LOB handling can provide their own version of the underlying class.

Though I am not in love with PostgreSQL, I have already written the INSERT code for that database. Without functions like this, we -- again -- would need an SQL query parser to be able to write special LOB handling which I still would prefer not doing. Also, you can provide options for a query, and this way we can support INSERT DELAYED without any problems -- any other database can simply ignore the delayed => TRUE in the options array.

The most important option is, however, target. You can specify a "target" for your query -- if such a target is defined in your settings.php then the query will be sent to that connection. This is how we support Actually, targets can be an array of connections, so we support multiple slaves. I want to add SQLite support and one of the roles SQLite could nicely fill in is a sort of caching database. SQLite is great for read-heavy applications, less great for write heavy ones. For this purpose we are adding a "cache" target. I have already raised the idea of actually writing some code which translates some SQL to memcached thus making it possible to send the 'cache' targeted queries to memcached...

To make this change easier, we are supplying a hack which makes it possible for current Drupal to run with the new layer. We are not keen on changing every query in Drupal core in one monster patch. We will remove that hack in due course, as the queries are changed to new placeholders -- and are using the new features.

All this is mostly Larry Garfield's work, I am just lending a hand. You can peek at the code at his sandbox but please note that this is very much being in formation.

I mostly have written this as a reply to a very confused blog post lately about what we want to do. Yes, I do want a lot of database handlers to live in contrib -- if they have a user base then it will be maintained, if not, then how could core support them?? If there are issues with core which hinder these, I am willing to work on resolving them -- same as any other contrib. Also, we always provided APIs which are not used by core but are there to answer some contrib needs. Looking at cross database issues, it seems our solution solved all problems aside from core using ANSI SQL reserved words. However, I only want drivers in core which have a chance of being properly maintained. I am willing to maintain SQLite and there is quite some interest about it -- during the last three years quite some people worked on an SQLite layer, so this seem to have the necessary following. MySQL is used almost by everyone, so that's there. Yes, I would like to see PostgreSQL moved to contrib but until that happens, I will grumble and work on it. Our work is not "sweed-poisoned-candy" but a massive effort to make it possible to support every database without hacking, to fulfill basically every database related feature request from the last few years.

Commenting on this Story is closed.