Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31453
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.198.186 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Cftr85jTiBAjf5fLrTvr3OZGvgNU3WtGSyeXfbmlpvdUlFMhTO0KLm5eaiV66qOCOqaeg37j5jcuzLgZp6oP9Su1fYUgVRERO2la7uLJhm/hjKzLDhGaW5x785Fb5IqI1o3GirI3XzhN+xIB/2uIm5Y+9cApYBxLpUOyhtdsnHk=
Message-ID: <fe05d1540708031408j189d37c2u5f4d1b4f25b7edef@mail.gmail.com>
Date: Fri, 3 Aug 2007 23:08:21 +0200
To: "Lester Caine" <lester@lsces.co.uk>
Cc: "PHP internals" <internals@lists.php.net>
In-Reply-To: <46B39172.6060300@lsces.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <87E4F8AF-06DE-4FCC-AD1B-83E932A5E180@prohost.org>
	 <46B2DDDB.6020801@lsces.co.uk> <46B2E196.4080400@zend.com>
	 <46B2FF97.3080302@lsces.co.uk> <46B3049E.5080309@zend.com>
	 <46B37FBB.5030803@quipo.it> <46B382E6.9000600@lsces.co.uk>
	 <fe05d1540708031240p391d0d1crb287b3e23112a115@mail.gmail.com>
	 <46B39172.6060300@lsces.co.uk>
Subject: Re: [PHP-DEV] 5.2.4RC1 Released
From: pierre.php@gmail.com (Pierre)

Hi Lester,

On 8/3/07, Lester Caine <lester@lsces.co.uk> wrote:

> Sorry Pierre I have to disagree there. Most flexible projects are built on
> ADOdb, and while you CAN use PDO as an alternative driver, for the best
> performance the raw drivers are preferable. I don't see anything to replace
> the SQL handling that ADOdb provides although the ADOdbLite does work well if
> you do not want a fully featured interface and can do without some of the more
> advanced SQL code.

Sorry, I was not clear enough. I did not say that PDO is perfect or
can replace MDB2 or ADODb, it is not its goal.

> Being able to build a project for ANY database is nice to
> have but requires you manage the SQL as well as the data, and if you are not
> building a generic project then you don't need a generic driver.

A common base is already a (very) good start. We obviously need more
and it is unclear how far PHP should go (talking about internals only
here).

> I keep being told that the PDO drivers can be extended to include all of the
> things already available in the native driver, but the second you do that they
> become incompatible, so in addition to the PDO driver you need to also run the
> native driver simply to provide the areas NOT covered by PDO. We need a
> generic framework that addresses the real problems not one that creates an
> artificial lowest common denominator strangle hold :( PDO could evolve into
> that, but not with it's current restrictions.

And what do you suggest to improve this situation? One of my
suggestions is to have more DB developers (as in DB internals, if I
can say so :) involved. Oracle and IBM (to name the largest and most
active) understood that and actively participate. I'm not saying that
you do nothing, but I'm not sure that complaining about the bad state
of pdo_firebird is really helpful.

Cheers,
--Pierre