Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29680
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.144 cause and error)
Message-ID: <4653DF96.9070201@lsces.co.uk>
Date: Wed, 23 May 2007 07:30:46 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <139872287.20070504170744@marcus-boerger.de>	 <736AED54-1272-4924-A07D-3166A1742A2F@prohost.org>	 <698DE66518E7CA45812BD18E807866CE2FEF72@us-ex1.zend.net>	 <463EDD0B.7080300@lsces.co.uk> <4e89b4260705222133y185892bdie46be2e78a2e471b@mail.gmail.com>
In-Reply-To: <4e89b4260705222133y185892bdie46be2e78a2e471b@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Starting 5.3
From: lester@lsces.co.uk (Lester Caine)

Wez Furlong wrote:
> On 5/7/07, Lester Caine <lester@lsces.co.uk> wrote:
>> No one has time to work on the
>> Firebird PDO driver because we still need the main driver to provide the
>> functions PDO does not support.
> 
> Umm, no.  Nobody has time for firebird because nobody uses it.
> I ask people about Firebird at each conference and I've never had more
> than about 1 in 50 people admit to ever having used it, and those are
> shaky hands going up--we're not talking die-hard firebird users here.
> 
> As for PDO missing pieces for Firebird, that's also untrue.
> 
> Perhaps you don't understand the PDO architecture, but PDO was
> designed by taking into account every database client API; it has
> hooks to cater for just about every conceivable way of passing data
> into and out of a database API.
> 
> It's the firebird driver that needs work.

No Wez - As far as I am concerned I need to load the non PDO driver for those 
areas that PDO does not support. As well as the PDO driver for the data based 
stuff *IF* I wanted to go down that route. But at present there is no good 
reason to switch.

User security, Event management, Services interface functions are not data 
based and while some of those functions are being moved into the Firebird SQL, 
things like Events can not go that route.

Now you may think that everything at the database end should be controlled via 
SQL, and that is probably the case, but as we have discussed long ago, *WE* 
still need ADOdb to provide the SQL abstraction so there is little incentive 
to work on PDO/Firebird/ADOdb when the current Firebird/ADOdb combination is 
fine and are currently working ( and ADOdbLite is the 'compact' version ). 
While ADOdb does support PDO, the best performance is still obtained with the 
raw drivers for each engine. If we are NOT working with multiple engines, then 
we work with the raw driver so again there is little need to spend scarce time 
replacing something that is working and has more facilities.

So until you provide a very good reason why we need to change - it's not going 
to happen. BLOB and parameter handling in the raw Firebird driver are a lot 
more flexible and simply sending a query with an optional array of parameters 
is much easier than HAVING to prepare everything - especially when the engine 
will cache things automatically anyway.

PDO simply changes the ground rules without solving any particular problem as 
has been said all along. Now you may well convince people that all the native 
drivers should be dropped from PHP and only PDO supplied but I hope that does 
not happen and that we have a PROPER debate on an abstract database layer.

-- 
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 Foundation Inc. - http://www.firebirdsql.org/index.php