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

Andreas Korthaus wrote:

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.

<snip /> I just want to make it clear, its not possible to *extend* the main PDO object easily, because the PDO::__construct() method is marked final, you cannot set your own constructor - the reasoning being that if you extend it, and fail to call parent::__construct() in your class, it causes a segfault. I personally feel this was a kludge fix. Oh well, __call() is my friend. <plug> Maybe you would like to check out Crtx_DB_DataObject [1], I've taken ideas from all over and I feel that I've melded them into a very nice lightweight package. Although still beta, its working pretty nicely for me and has a pretty good test suite. Currently some very simple LIMIT "abstraction" is done, basically if the DB doesn't support the LIMIT start,offset syntax you can opt to do the lIMIT automatically in PHP. I have done some *very* minimal nextID() abstraction, by that I mean, if it doesn't work without specifying an argument to PDO's nextID() method and its not PostgreSQL it won't work. This is only a 0.5.0 release however, so theres plenty of room for improvement, but I would appreciate some help if anyone is willing :) I would just like to voice a thought I've had on Crtx_DB_DO, I don't want to bloat the class with lots of portability stuff - its the reason I've used PDO directly instead of MDB2. However, I'm happy to do some very basic checking for popular DBs with *similar* enough syntax and support those in this core class. Then I would rather create say a Crtx_DB_DataObject_Oracle class tailored specifically to Oracle, same for MSSQL - these are enterprise level DBs, and its pretty safe to assume that you are working with lots of data when dealing with them, I would rather not bog them down with any abstraction code at all, its all hard coded specifically to those DBs. </plug> - Davey