"Stig S. Bakken" wrote:
> Joao Prado Maia wrote:
> >
> > On Wed, 21 Nov 2001, Martin Jansen wrote:
> >
> > > On Wed, 21 Nov 2001 09:19:44 -0500 (EST), Joao Prado Maia wrote:
> > >
> > > >If PEAR::DB is not abstracting the database what is the purpose of such a
> > > >library ?
> > >
> > > To ease the life of lot's of programmers.
> > >
> >
> > I probably used a bad choice of words. What I really meant was: What is
> > the objective of PEAR::DB as a database abstraction library ? To abstract
> > as much as possible like Metabase already does, or to provide a unified
> > API to databases and leave the implementation related to database specific
> > to the user himself ?
> >
> > It's okay to choose the latter, but I believe we should have a unique
> > position on something like this, so we know what we are working for. A
> > statement like this will be very helpful when people come to the mailing
> > list saying that PEAR::DB doesn't abstract LOB's or any other exotic
> > feature, as we can just reply "that's not our objective".
> >
> > Anyway, I think this is a good discussion.
> PEAR DB's objective was to provide a common API.  This is why I did not
> choose Metabase for PEAR in the first place, IMHO it was too huge and

After almost two years PEAR-DB is still catching up with Metabase
features, for instance, sequences, limits in select queries, etc... When
PEAR-DB catches up on the current Metabase features it will not be
smaller than Metabase. The difference is that it will take even a longer
while to catch up than it already took today.

What is worse is that it is under-documented and subject of permanent
API changes. Take for instance, the recent changes on the way to specify
limits to select queries. First, they decide that setting the query
limits should be coupled actual query execution. Then they realize that
setting the limits of prepared queries have to be done before executing
the query. So, the latest solution is doing exactly as it is done with

If this already like this with limits in select queries, I can imagine
how it will be like when somebody finally decides that PEAR-DB needs an
interface for handling BLOBs. I guess it will be something like
everybody jumping in with their own ideais on how to store and retrieve
data from BLOBs, leading to several incompatible versions of the API
functions to do that.

You have to admit that this is silly. The real problem is that this
experimental character of PEAR-DB is annoying to most users because they
do not have a stable API to rely on, nor do they have an expectation on
when PEAR-DB API will ever be stable and properly documented. So for a
lot of people, PEAR-DB is as good as non-existing.

My proposal to wrap PEAR-DB around Metabase is exactly to address this
current PEAR-DB deficiencies and stop the PHP bad fame of lacking of a
database abstraction layer. Metabase API is stable and througly
documented. Metabase manual not only documents the features and the
functions, but also has a pedagogical approach because it explains
clearly with some detail complex concepts like prepared queries,
transctions, blobs, etc...

Manuel Lemos

PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to