Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31489
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 85.10.196.195 cause and error)
Message-ID: <46B97C3C.6010405@pooteeweet.org>
Date: Wed, 08 Aug 2007 10:18:04 +0200
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Lester Caine <lester@lsces.co.uk>
CC: PHP internals <internals@lists.php.net>
References: <87E4F8AF-06DE-4FCC-AD1B-83E932A5E180@prohost.org> <46B41A47.1080902@lsces.co.uk> <46B81302.1060403@lsces.co.uk> <200708072345.58330.larry@garfieldtech.com> <46B9797B.6080304@lsces.co.uk>
In-Reply-To: <46B9797B.6080304@lsces.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-backendmedia-com-MailScanner-Information: Please contact the ISP for more information
X-backendmedia-com-MailScanner: Found to be clean
X-backendmedia-com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=0.078, required 6, AWL -0.02, RDNS_DYNAMIC 0.10)
X-backendmedia-com-MailScanner-From: mls@pooteeweet.org
X-Spam-Status: No
Subject: Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
From: mls@pooteeweet.org (Lukas Kahwe Smith)

Lester Caine wrote:

> The main thing I see there is 'raw' SQL. Loading the variables directly 
> into the script, rather than simply binding them as params. I have yet 
> to work out a way of converting some of my dynamically generated SQL 
> into a format that will work with PDO - on any database. I've only ever 
> used ADOdb and that handles ALL of the parameterizing of things 
> transparently.

I have no clue what type of dynamically generated SQL you are talking 
about. Are you talking about being able to dynamically stick identifiers 
into placeholders? This is simply not possible if you are using native 
prepared statements. If you emulate them, yes you can, but then you can 
might as well use sprintf() with quote() (maybe with a wrapper).

> The other problem of cause is length of table and field names and 
> reserved words. Adding Oracle and MsSQL to the mix, working with raw 
> upper case table and field names and 31 character name limit introduces 
> a few extra things to consider over and above just adding PDO to Drupal ;)

PDO handles some of those, but as said tons of times before, its not an 
abstraction layer, its an API unifier. There are PDO based layers like 
Doctrine, that give you all the convinience of ADODB (and more ..). They 
do however require that the underlying PDO driver is solid.

At any rate .. why bother with PDO when there are "native" extensions? 
The point of PDO was not only end user focused, it was also the idea to 
one day make it less effort to add new features to all the RDBMS 
extensions (for example unicode .. that being said I keep hearing that 
PDO HEAD is totally out of sync). It also makes it a lot easier to add a 
new RDBMS extension.

Now if we stick with maintaining the current non PDO extensions, then 
you must realize that we are maintaining a lot of redundant code, which 
is based on one of the oldest extensions (ext/mysql). Since we do not 
have infinite development resources, it would be for the better of any 
of the supported RDBMS if it would get its PDO driver up to the same 
level as the old extension. As more and more of our userbase is moving 
to PHP5 this hopefully will become more and more interesting.

regards,
Lukas