Pierre wrote:
Hi Lester,

On 8/3/07, Lester Caine <[EMAIL PROTECTED]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to