MDB2 development has been a lengthy process indeed. As a matter of fact development began back in the summer of 2003. Now two years later the fact of the matter is that MDB2 has been useful for production purposes for the past 1,5 years and all that really stopped it from going stable is the final decision to mark the API as stable.

That is not to say that the past 1,5 years were wasted on API changes alone. Alot of things where tweaked, performance improved and useability drastically improved. Most PEAR modules that can talk to a database support MDB2 natively etc. However life as an MDB2 user was full of suprises (not as much for those that actually read the changelog) on every update and I think its really about time this ends.

So I am finally dropping the idea of PDO API compatibility once and for all. This will mean that any PDO based drivers will have to wrap rather than extend PDO. This is unfortunate but so it goes. I assume that someone will sooner or later create an E_STRICT PDO based layer in PEAR sooner rather than later. MDB2 will probably proof to be a very useful ressource for this undertaking.

I did a few commits today that cleaned up some aspects of MDB2 due to the half baken attempts at API compatibility with PDO. Aside from that the main taskes left open can be viewed in the todo list.

In terms of drivers the status is as follows (note the goal is to have atleast two maintainers per driver):

• mysql (pretty solid, autoincrement/primary key support more or less done, might need another maintainer)
• mysqli (pretty solid, autoincrement/primary key support needs to be ported from the mysql driver, might need another maintainer)
• sqlite (pretty solid, autoincrement/primary key support missing, needs another maintainer)
• ibase (pretty solid, autoincrement/primary key support missing, might need another maintainer)
• pgsql (pretty solid, autoincrement/primary key and native prepared support missing, might need another maintainer)
• oci8 (pretty solid, autoincrement/primary key support missing, LOB null handling broken, might need another maintainer)
• querysim (not tested in a while, needs maintainers)
• mssql (getting upto speed, autoincrement/primary key support more or less done, might need another maintainer)
• fbsql (not tested in a while, autoincrement/primary key support missing, needs maintainers)

If you are interested in becoming a maintainer it works like this: I will be quite liberal with the fbsql and querysim drivers. For the other drivers I first expect a few useful comments/patches. Eitherway its probably one of the easiest ways to get a PEAR account and cvs.php.net karma. I will be there to hold hands a bit if needed.

Aside from that I would welcome of course addition of new drivers for databases like informix, ingres, odbc, maxdb, db2, sybase etc. Furthermore help on extending the unit tests and documentation are also obviously much desired. Time to come out of the closet onto the international php scene people!

Does PEAR::DB wrapper started to work? I couldn't find that info in changelogs.

I have been slacking severely on the PEAR::DB wrapper. Mainly for 2 reasons:

1. I thought nobody cared
2. It has become increasingly hard to maintain the wrapper as I as moving towards the PDO API

However it seems enough people care and I have decided to stop migrating towards the PDO API. So I will try to pay more attention to the wrapper. That said the wrapper should work more or less atleast.

Please note however that most PEAR packages that support PEAR::DB already have PEAR::MDB2 drivers these days. So there is less and less of a reason to use a wrapper.

It all depends on how big the application is - in my situation porting it to MDB2 would be too much work to do and therefore wrapper seems to be better idea, however I realise that MDB2 is a way to go for future projects.
Also, I'm not sure that situation with PEAR packages is as good as you wrote it, e.g. DB_DataObject doesn't have MDB2 driver, am I right?
And finally having wrapper working would be cool for Seagull - I don't know how their plans for adapting MDB2 looking but I imagine it will take some time until they do that.

DB_DataObject has an MDB2 backend (note its MDB2 not MDB as the changelog might imply). Its kinda hacky, but less hacky than using a wrapper.

But sure .. it might be the only path when you cannot migrate in one go.