Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31491
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.143 cause and error)
Message-ID: <46B98962.7020002@lsces.co.uk>
Date: Wed, 08 Aug 2007 10:14:10 +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> <46B41A47.1080902@lsces.co.uk> <46B81302.1060403@lsces.co.uk> <200708072345.58330.larry@garfieldtech.com> <46B9797B.6080304@lsces.co.uk> <46B97C3C.6010405@pooteeweet.org>
In-Reply-To: <46B97C3C.6010405@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
From: lester@lsces.co.uk (Lester Caine)

Following on ....

Lukas Kahwe Smith wrote:
> 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).

OK this is a key difference between MySQL and other databases - at least 
looking at the raw drivers. Firebird ( and PostgreSQL ) can use parameters to 
handle the transfer of values to the query.
 From pg_query_params manual - "The primary advantage of pg_query_params() 
over pg_query() is that parameter values may be separated from the query 
string, thus avoiding the need for tedious and error-prone quoting and escaping."

Most projects I work with, build an array of values to be processed, and then 
just create a simple SQL query to pass the array to the database.

PDO does wrap this quite nicely, except that BLOB's can only be passed as raw 
content? The ability to just pass a BLOB ID means that you only access that 
part of a large blob that you need. And most database engines would benefit 
from being able to handle BLOB elements independent of the general fetch. 
Rather than duplicating and processing several hundred 'k' text blobs, you 
just pass the link to the original?

>> 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.

The IDEA is still good. It just needs the core tidying up a little more before 
it becomes totally practical.

> 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.

Having finally got to the point where PHP4 *IS* being end of lifed, then one 
of the major stumbling blocks HAS been removed. That is why I *AM* now coming 
back to this - after 2 years - and trying to nail down some of the remaining 
problems. I have had to be careful even with the Firebird driver to ensure 
that only functions available in PHP4 are used in ADOdb, but it will be nice 
to be able to say - that version of project X is the last which will support 
PHP4!

NOW we can get on and start looking for PHP6 and proper Unicode support - 
Firebird can run DIFFERENT character collations in each field something else 
that still needs the native driver to handle ;)

-- 
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