RE: [PHP-DEV] Advice on design issues (long)...

From: Date: Mon, 25 Mar 2002 17:03:48 +0000
Subject: RE: [PHP-DEV] Advice on design issues (long)...
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-5103@lists.php.net to get a copy of this message
> the DB abstraction problem is a much larger one, which Manuel (and > yourself) > have been struggling against with serious handicaps. for instance, one of > the reasons Manuel had to put so much work into Metabase is that the > original extension writers did not provide metadata which is readily > available from the database itself, or the metadata supplied is > inconsistent > across back-ends. Yes a while back Zak come to php-dev propsing to do a more OO-style interface to MySQL. There was a bit of screaming and moaning about why a OO only interface and why another one and why not a unified one for all RDBMS. I think in the end Zak said he will do it anyways just for kicks ... iirc I think this is a major source of uglyness of php having so different interfaces to all the various RDBMS. Most of the "db abstraction" packages are more about cleaning this uglyness than abstraction. I have not checked into dbx was much was I wanted (or should), but I have heard that he is also moving forward. > ive done quite a lot of legwork on this, and i think i have a framework > which accomodates everything from MySQL to Oracle. i did MySQL first > because > 1) the API is simple 2) i needed to quickly write a driver to test some > basic design decisions (navigation and bulk-fetching). Yeah you gotta start somewhere ... MDB currently also only supports MySQL The other advantage is that you then have a zillion people that can easily test your stuff. So doing MySQL makes sense (as long as you keep the other DBs in the back of your head) > note that i dont think that Metabase or ADOdb will necessarily go away if > this extension works out. there are things that you and Manuel do that i > think belong in user-space and not in an extension. for instance your > sequence emulation code modifies the DB schema, which crosses the line of > an > access layer. also Manuel's schema abstraction and transformation is > another > example. Yes, somethings should stay in userland, or can stay in userland because they are not used as often or mostly don't need the speed improvement to warrant to extend and maintain a C extension. I wonder if it would be possible to somehow allow people to "extend" object that are provided by a C extension in userland. That would be really cool. (I don't know enough about php extensions to really tell .. but maybe that would be a nice feature request for php5?) > i only really care at this point about data and metadata acess > abstraction. what it means though, is that your PHP code will be > considerably smaller and faster ( i think i can eliminate the need for at > least 65% of Metabase's code). Speed is good :-) Lukas Smith smith@dybnet.de _______________________________ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de info@dybnet.de _______________________________

« previous php.pear.dev (#5103) next »