Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31451
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.134 cause and error)
Message-ID: <46B39172.6060300@lsces.co.uk>
Date: Fri, 03 Aug 2007 21:34:58 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070716 SeaMonkey/1.1.3
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
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>
In-Reply-To: <fe05d1540708031240p391d0d1crb287b3e23112a115@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] 5.2.4RC1 Released
From: lester@lsces.co.uk (Lester Caine)

Pierre wrote:
> Hi Lester,
> 
> On 8/3/07, Lester Caine <lester@lsces.co.uk> wrote:
> 
>> Ard was amongst the list of people who could not see any need to develop a
>> second driver since the php_interbase one IS working fine. It would be nice to
>> build a Firebird version against the modern client, and do away with the need
>> to build a legacy client to allow it to work. That IS in the pipeline, but as
>> yet no-one who uses Firebird/PHP in production has seen any need to spend time
>> on a more limited PDO driver ;) Ard had built a lot of capability into the
>> driver, and has added all the hooks for an fbird port already for a split,
>> which is probably now due given the extensive work Firebird has received in
>> the version 2 builds, and the new service facilities that it would be nice to
>> support directly. But even the existing php_interbase handles FB2.x without a
>> problem.
> 
> That's nice and I'm sure Ard's work is highly appreciated by the
> firebird users. But I completely disagree with this strategy (mysql
> follows it too). In the long run you will simply loose more php
> "market" in favour of databases with good PDO support.
> 
> I'm not saying that PDO is perfect (it is not), but pdo adoptions is
> growing and to be supported by PDO becomes more and more a must.
> 
> I would to see more databases developers helping the PDO developers to
> improve it, to add what they need to write good drivers. It will be
> all benefits for the PHP users and for the DB developers (if they want
> more customers/users).
> </utopia>

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. 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.

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.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php