Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14861
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Sat, 12 Feb 2005 10:22:49 +0100 (CET)
To: Lester Caine <lester@lsces.co.uk>
cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <20050212090244.59428.qmail@lists.php.net>
Message-ID: <Pine.LNX.4.58.0502121013420.18738@localhost>
References: <4e89b4260502111655215a94e8@mail.gmail.com>
	<20050212074627.64626.qmail@lists.php.net> <4e89b426050212001234271b83@mail.gmail.com>
	<20050212090244.59428.qmail@lists.php.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Re: Please test PDO
From: derick@php.net (Derick Rethans)

On Sat, 12 Feb 2005, Lester Caine wrote:

> Wez Furlong wrote:
>
> ADOdb is a well established abstraction layer.

And there are others too: pear:db, mdb, metabase...

> > If you want a database abstraction layer, stick with ADOdb and let
> > John adapt that to run on top of PDO.
>
> GERRRR!!!!!!
> WHY BOTHER !!!!
> Can't we pull together and push towards a SINGLE standard abstraction
> layer, rather than seemingly playing with bits and creating MORE work
> adapting perfectly stable code.

1. ADOdb has *nothing* to do with the PHP project
2. Some people don't need bloated libraries as ADOdb and still want to
   have one single unified interface to databases - THAT is what PDO is
   for: raw access.

> > WHY can't you be bothered to read the resources I've pointed you all
> > at, where I explain this?
>
> Because *I* am trying to open the debate as to why we are forcing more
> modules into PHP that do not seem to have been fully thought out.

How do you know it wasn't thought out? Were you there at the PDO meeting
where most PHP's DB maintainers where?

> If the
> effort put into PDO had been directed to the core of ADOdb we would HAVE
> all the functionality of PDO - WITH the remaining problems being
> addressed as well and a path to generic database generation. Instead
> work has now got to go into 35 drivers in ADOdb as well as the core
> library *IF* PDO is to be used.

Again, ADOdb is a PHP USERLAND solution, PDO is not. PDO is C, PDO is no
bloated OO, PDO is fast.

> Your SQL code will still be engine
> specific, and the bulk of the changes will be in that area. So people
> need to be aware of *ALL* the limitations of PDO before they spend too
> much time going down a potential dead end!

Sure, SQL needs to be changed between some engines but that is not the
point of PDO as Wez already said a couple of times. PDO is providing a
single unified API to database extensions.

> At the present time PDO is not suitable for me and just seems to be a
> waste of expertise that could be directed to something much more useful
> such as improving the core performance of ADOdb :(

Feel free, I don't care what you want to use - if you don't care about
PDO, fine with me, good luck with ADOdb.

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org