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

Andreas Korthaus 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 ;-)).

My main grudge is with putting in context sensitive behaviour into methods. This seems very confusing to me. There are lots of little details that add up IMHO.

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.

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. 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.

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 ;-).

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.

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

Essentially the work there is to look at all the mappings in the driver again. It was infact impossible to squeeze the SQLSTATE errorcodes into the existing error codes. I have begun this.

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?

You should go with the PDO API in that case, because otherwise you will need to wrap and not extend from PDO, which seems to defeat your thin layer requirement. MDB originally was meant as a replacement to DB, but there was never a push towards this in PEAR. I guess this is one of the problems I am facing right now. It doesnt matter how fast I make MDB2, how flexible, how feature-rich .. people seem to be happy with DB (alot of them because they accept the deficiencies thinking that MDB2 must be slower or something). 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. I guess thinking about it some more I am just tired of what feels to me like an uphill struggle inside MDB2 that for the most part I have been doing alone (with Lorenzo). I guess the problem is that MDB2 fit my needs long ago and I started to try and please others and those others did not care. I guess opensource is always about pleasing yourself and hoping others like the same stuff :-) 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. But to answer your question: yes I think there is room for a PDO based thin yet extensible layer in PEAR. I would like to think that MDB2 could be adapted to become just that or atleast some of its ideas could assist there (I think you will only be able to be extensible using __call(), since you dont have multiple inheritance in PHP5). regards, Lukas