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

On 8/3/05, Lukas Smith <lsmith@php.net> wrote: > 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. Although I haven't looked at the methods you mention, I don't like the idea of this context sensitive behavior either. > > > 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. And, as should be mentioned, MDB2 has been shown to be faster that pretty much anything but bare function calls. I'm very impressed with the work you've done. > > 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). > :-( I feel bad for possibly contributing to this feeling for you. I've always thought that MDB2 would become the next version of DB or at least be favored instead of DB. I just never made the switch myself because I've gotten very wel entangled in DB_DataObject_FormBuilder, which depends on DB_DataObject, which depends on DB. Some work has been done to make DB_DO work with MDB2 but it's a hack inside other hacks. DB_DO has lots of rough edges, as does FormBuilder. Perhaps the time has come to start a new MDB2_DataObject from scratch. I know this has been said before, but this time I actually plan to do something about it. It would be nice, however, to have a design discussion of some kind. I don't want to just get stuck in the mindset of replicating DB_DO as it is now. -- Justin Patrin