Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31483
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 206.18.177.56 cause and error)
To: internals@lists.php.net
Date: Tue, 7 Aug 2007 23:45:57 -0500
User-Agent: KMail/1.9.6
References: <87E4F8AF-06DE-4FCC-AD1B-83E932A5E180@prohost.org> <46B41A47.1080902@lsces.co.uk> <46B81302.1060403@lsces.co.uk>
In-Reply-To: <46B81302.1060403@lsces.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200708072345.58330.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
From: larry@garfieldtech.com (Larry Garfield)

On Tuesday 07 August 2007, Lester Caine wrote:
> Lester Caine wrote:
> > Christopher Jones wrote:
> >> Lester Caine wrote:
> >>> 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.
> >>
> >> Can you list the current restrictions as you see them?
> >
> > Actually the very first one has been addressed and has nothing to do
> > with PDO. Up until recently is was essential to provide backwards
> > compatibility with PHP4 and all of the projects I currently work with
> > WOULD still install on PHP4. Although *I* never used it in production,
> > the continued support meant that there was a large base that insisted on
> > retaining it. So ADOdb's continued underlying support for PHP4 is useful
> > and until there are a higher percentage of PHP5 users than PHP4 - PDO
> > takes second place as it is not available on a large number of hosts?

As you noted, this one is no longer an issue[1][2].

[1] http://gophp5.org/
[2] http://www.php.net/index.php#2007-07-13-1

> > The next problem builds on the above one. From the PDO manual "PDO does
> > not provide a database  abstraction; it doesn't rewrite SQL or emulate
> > missing features. You should use a full-blown abstraction layer if you
> > need that facility." ADOdb will run PDO drivers quite happily, but on
> > current information the performance of the PDO drivers is slower than
> > using the same native driver. So given a choice the native one is
> > preferable and currently essential for PHP4 support.

I've seen some of the numbers posted, at least as far as MySQL.  As Ilia has 
noted before, MySQL's native prepared statement support sucks all on its own.  
It's faster to use PDO's internal implementation.

That said, you need to make a direct comparison.  PDO, especially with 
prepared statements, does a lot more processing than a direct implementation.  
That takes a lot more cycles than just passing mysql_query() a string.  
However, just passing mysql_query() a string is not secure.  You need to 
implement your own escaping mechanism on top of it (because trusting yourself 
to always call mysql_real_escape_string() in every instance is a recipe for 
disaster).  That takes even more cycles, because it's happening in PHP rather 
than in C.

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

> > 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 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?

> > PDO provides a basic transaction control that hides the transaction
> > modes. It can't handle retaining the context of the transaction
> > following a commit or roll back, or selection a more appropriate
> > transaction mode? CONCURRENCY for reports at a fixed time point over
> > COMMITTED to handle changes made in other transactions. How does one
> > switch between a 'wait' and 'nowait' transaction?
> >
> > The one that prompted this discussion. How do you return a simple handle
> > to a BLOB object so that you DON'T have to download the whole blob. It
> > can be useful to hold the blob id so that you only access a sub set of
> > the data from the blob object. This seems to be missing in PDO?
> >
> > HAVING to maintain PHP4 support has meant that I have not gone into PDO
> > with a fine tooth comb, and most of my understanding of the problems of
> > PDO is based on what has been said elsewhere, but at present I can't see
> > how some of these fundamental facilities provided by the php_interbase
> > driver would be mirrored in PDO. I stand to be corrected, and perhaps
> > when PHP4 has died THEN the supposed advantage of PDO may be a more
> > attractive development path? But at present there is simply no incentive
> > to move over :(
>
> Things went quiet :(
>
> Is there anything in my above list this is NOT correct? I do stand to be
> corrected about PDO, but at present I can't see how to get around the
> limitations even IF the pdo_firebird driver was functional. And I see some
> of these restrictions applying to other database engines as well?

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.

-- 
Larry Garfield			AIM: LOLG42
larry@garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson