DB, MDB2, PDO - Future of DB-Abstraction in PEAR

Hi! Lukas Smith wrote:

I aked about what to do with the differences between the MDB2 and PDO API a while back and the only feedback I got was "go with the PDO API". It does seem like the sensible choice. However I just cant motivate myself to move over to the PDO API, which imho is very user unfriendly.

I wouldn't call it "very user unfriendly". I can understand why you don't like some parts of the PDO API. But other people don't like parts of the PEAR (M)DB API. In my opinion the points you mentioned in [1] don't make the PDO API "very user unfriendly". When I'm writing scripts using MDB2 or PDO, the differences aren't that big. Wez took some inspiration from ODBC, OCI and Perl DBI [2], those have been designed by people that "live and breathe databases" (to use Wez' words ;-)). Anyway, since RC1 of PHP 5.1 will be released soon, the PDO API won't change anymore, we have to live with it and have to make the best of it. I also don't like some parts of the MDB2 API, but I use it in production (though it is beta), because it's the best DB abstraction I know. Same with PDO, it's a trade-off and I can live with it (actually very well).

Maybe someone else wants to take up this task. I am willing to hand over lead of MDB2 to that person. I will help with questions about MDB2 of course and I will help maintain the drivers. I just cant force myself to spend any time on turning the MDB2 API into something I dont believe in.

I also recommended changing the API to MDB2 some weeks ago - but if I think about it again (after looking into the details), I'm not sure if it's worth it. I think I will switch to PHP 5.1 before MDB2 with PDO API would become stable, or even usable ;-) If you are not interested in changing your API to the PDO API for PHP4-users I understand absolutely that you don't want to waste your time with it. The question is - what will be the future of DB abstraction in PEAR? I'd love to see a very thin abstraction layer based on PDO which only adds essential features like "row limit" and "sequence emulation", to make it possible to write DB intependent code, if you use simple SQL. But if I look at the feature list of MDB2 [3], I think many people have different needs, and I expect such a db abstraction will be similar feature rich as MDB2 is today. Perhaps the DB abstraction could be splitted in different packages, a basic package with a very lightweight layer (as described above), a feature rich package as MDB2 based on the lightweight package or a common base package, a data object package (like DB_DataObject), a schema package (like MDB2_Schema), perhaps a "lazy" package which adds methodes to the basic package like "autoExecute"... In my opinion, such a DB abstraction should use as much PDO as possible and if it is not much more inefficient it could wrap PDO. Where is the 'big' advantage in extending PDO and PDOStatement [4]? (Performance? How much?) Perhaps it could support different APIs (such as DB, MDB2, PDO), perhaps a different package for each API with a common base package... What I don't like so much is the module-approach in MDB2. I don't like to use $dbh->extended->methode() if I want to use special things like autoExecute(). And I don't like to use __call() or $dbh->myPREFIXmethode() to avoid that (that's the part of the MDB2 API I don't like so much ;-).

As such I will try to finish up the SQLSTATE error codes as well as auto incrememnt support.

I have looked at this and some other differences between MDB2 and PDO - every point - even if it sounds simple as "matching SQLSTATE error codes" - turned out to be really difficult at closer inspection. If you think it's better the way it is - leave it at that. I myself don't like to put too much mork in MDB2, because I know I'll stop using it once I have a PDO-based alternatve. Furthermore I don't use many features/code of MDB2 and PDO will cover most of it (but not all). I'm not sure if I should write an own, lightweight DB layer or if there will be a PDO based layer in PEAR soon. At the moment I'm not sure if I should prefer the MDB2 API, or try to switch to the PDO API - if possible. A major disadvantage of an own DB layer is that I can only develop and test 2 or 3 drivers. If I need a new driver I have to write it from scratch and it won't be tested in any other application. On the other hand it will not be that much code, only if you have to support the complete DB or MDB2 API and all those features, it becomes much more complex. So I'd like to see such code in a seperate package. What would be the preferred API for such a PDO based DB package? Make it easy to switch for users of PEAR::DB, or make it easy for users of PDO? If there will be a new package, I'd recommend to develop a nice package for the future, and BC should not be so important, because I think DB developmant will go on... But if people start using PDO and have to switch to another database, it would be great to switch easily to a PEAR packages with the need of only some minor fixes... I'd like to hear your opinion on that subject and if there are any plans for a PDO based DB abstraction in PEAR. Thanks a lot! Best regards Andreas [1]: http://blog.backendmedia.com/blog/__/__/_MAIN_/mode/thread_show/thread_id/225 [2]: http://netevil.org/node.php?nid=296&SC=1 [3]: http://oss.backendmedia.com/index.php?area=MDB2 [4]: http://cvs.php.net/co.php/php-src/ext/pdo/tests/pdo_023.phpt