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

Lukas Smith wrote:

Well MDB2 has all the makings of exactly this. MDB2 is a thin layer with lots of optional modules. This could be pushed a bit more (like using prepared queries forces you to load the datatype module), but its one of the key ideas of MDB2.

But If I look at PDO, the only additional functionality I need is portable LIMIT support and portable sequences (like $db->nextId()). The only problem why I had to extend PDOStatement today, is missing support for a defaultFetchMode in PDO. I don't want to set the fetchMode for each query or each statement. There is a feature request in the bug-tracker: http://pecl.php.net/bugs/bug.php?id=4732 If that could be implemented (by an extra PDO methode or attribute), I would be completely happy with PDOStatement itself. Another very nice feature would be to set the PDO_ATTR_STATEMENT_CLASS attribute in PDO itself, so you could use your own StatementClass without setting it in each PDO::prepare() call. It could also work with PDO::query() that way: http://pecl.php.net/bugs/bug.php?id=4987 (Now PDO_ATTR_STATEMENT_CLASS does not work with PDO::query() at all, you have to wrap/overwrite it and usee prepare(), execute()) For now I would not need it if defaultFetchMode would be implemented, but if you still need your own statement class I think it would be very useful anyway. This way I don't need to extend PDOStatement and also extending PDO would not result in many advantages I think, but it was very easy anyway. So the only task I had to do would be writing drivers (or perhaps an abstract helper-class with drivers for each DB-engine), which implement LIMIT and sequences. I could load the matching class from my DB class (which extends or wraps PDO) per lazy load (I don't need LIMIT and sequences in every script), so such a DB layer would become really simple and I think it would cover all scripts I've written in the past. If PDO::defaultFetchMode() (or a corresponding PDO attribute) was implemented, such a *very lightweight* DB layer basically could look like that: http://www-users.rwth-aachen.de/andreas.korthaus/db.phps (It's just a hack, I know I'm missing a lot of stuff, but that's to show the basic functionality I have in mind now) This covers most of what I've done with PEAR::DB or MDB2, and in addition I can use all those nice PDO features in future. But if defaultFetchMode was not implemented, it becomes more difficult, I had to wrap the PDOStatement class... and I'd like to avoid that. Additionally - if PDO_ATTR_STATEMENT_CLASS was not implemented in a nicer way, I also have to wrap PDO::query(), PDO::prepare()... OK, that's all possible but I'd love to avoid it.

So all that needs to happen is work on PDO based drivers and maybe some tweaking here and there to make sure that people can effectively use MDB2 with PDO based drivers. However in order to make it a thin layer MDB2 must adhere to the PDO API as much as possible, or it will wrap instead of extend PDO. However maybe its better to start this off from scratch.

If I look at MDB2, it's very mature and feature rich, MDB2_Driver_Common implements a lot of things PDO implements today. And if I write PDO drivers for MDB2, I cannot use many features of PDO if I don't implement it in MDB2. However, if I had to support as many features as MDB2, I'd go with MDB2 and change it on that basis. If I write something for my few features, writing it from scratch is easier I think - but in this case I would steal a lot of nice code from MDB2 ;-)

Heh, well I guess with PDO you could try to work around this to some extend since IIRC you get the same class regardless of the driver chosen, so you dont run into the same issues. In that case you would need to handle all driver specific code inside a single class. This is what DB_DataObject does and I find this to be a much greater evil and it simply doesnt scale beyond a single developer properly.

PDO implements a lot of functionality, there is only very little driver specific code needed (for me!) as shown above. But if methodes like DB::autoInsert() should be removed from the core class (which is a good idea if other people want to use it too) I must use __call() to make it work in a nice way - but without a prefix ;-)

However I think a PDO based layer has a much better shot at adoption, since it will be clearly faster in the minds of everybody and because it will be E_STRICT compliant.

In my opinion MDB2 is better, but there are many reasons why people still use DB: 1. it's stable 2. it's used a lot, well known... 3. it supports most features most people need (coming from mysql-extension) 4. it's fast enough for most people 5. most people don't need more flexibility

So at this point I really dont know what to do, but my motivation is very low to continue on MDB2 with the current environment.

Perpaps it's a good idea to bring the MDB2 API as close to the PDO API as possible (as far as it is little effort) - but this has to be done by people seeing any advantage in it for their own projects. I think it's useful to make the switch to PDO as easy as possible, but if you're happy with the current API - leave it as is. For me the switch will not be very difficult, changing the MDB2 API will be much harder. I'd prefer to put my efforts on a PDO based DB layer. What do you think about my suggested approach? What do you think about the 2 feature requests and their chances to make it into PDO (soon)? Thanks for your answer! Best regards Andreas