RE: [PHP-DEV] Advice on design issues (long)...
| From: | Lukas Smith | 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
_______________________________