Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31488
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.146 cause and error)
Message-ID: <46B9797B.6080304@lsces.co.uk>
Date: Wed, 08 Aug 2007 09:06:19 +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>
In-Reply-To: <200708072345.58330.larry@garfieldtech.com>
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)

Larry Garfield wrote:

> As a case in point, I recently tried to implement a PDO layer for Drupal as an 
> alternative to the mysql_* implementation.  Drupal currently implements its 
> own prepared statements in user-space, using a printf()-like syntax and 
> preg_replace_callback().  When I replaced that with PDO's own prepared 
> statements, I found performance was about a wash[3].  On the other hand we do 
> get type-safe prepared statements and simpler code, so we're planning to move 
> to PDO in Drupal 7 at this point.
> 
> [3] http://drupal.org/node/134580

That nicely summaries some of the aspects of moving to PDO from the user side. 
You are thinking that you will have to support PHP4 and non-PDO drivers until 
2012 :)

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.

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 ;)

>>> NEITHER of the above are restricted to Firebird and apply equally to all
>>> databases, but they are the main reason to date that no one has had the
>>> inclination to fix the pdo_firebird driver as it's deployment potential
>>> is currently limited.
> 
> My knowledge and experience with Firebird is nil, so I cannot say anything 
> useful for that.

The only point I was making here is the one you have covered - we need to 
support PHP4 for some time yet - which ever database you are using :(

>>> The internals of PDO restrict things to using SQL access to the
>>> database. While it will probably be said that the database should ONLY
>>> provide SQL access to everything, Firebird has a services interface
>>> which is used for such things as backup, user management, and the event
>>> handler. How should all those be handled if they are moved to the PDO
>>> driver?
> 
> Are you talking about Firebird-specific features, or all non-SQL-standard 
> queries?  As far as I know PDO allows arbitrary strings as queries so 
> SQL-esque database-specific stuff should still work.  Wez, is that not the 
> case?

There are other interfaces other than just the 'SQL' one for talking to but 
then the database industry are working from the other end to come in line with 
the standards. Perhaps another one for 2012.

> I make no claim of being a PDO expert either, and my database experience is 
> 98% MySQL, but the above is my experience and reading so far with it.  PDO's 
> main selling points are 1) A fully OO API and 2) A common API for all 
> databases.  By nature, it does result in "lowest common denominator" issues 
> as well, including potentially performance.  If you're aiming for 
> cross-database compatibility, I'd recommend it over rolling your own.  If you 
> can guarantee that you'll only need <insert some database here>, then the 
> specific driver may be a better option in some cases.  YMMV and so forth.

TODAY - I think that is right.
I'm not as negative about PDO as people seem to think! It is just that TODAY 
there is a packaged working solution to MY problem, which many other people 
are using as well so there is no need to spend time 'rolling your own' version 
of PDO that mirrors those facilities?

-- 
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