Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31485
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.166.180 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=NLoxtTzucFWp5MOZQ1f1jZM5P+aAjEg7BAao82vm9N58hYoylcy58ofiybgXi/ZX4PemqPzQP/HXPO8nOKi6XmHxyknN2ecebwxAx7fToFl+h7BN333HKFfKIuRdSrZTptgw8F724BZGhFXmM2GpIKjdqvE0gmpJqbyRzyQF4ew=
Message-ID: <fbb0d11d0708072237q5cd83632sa5a7fa942676a0de@mail.gmail.com>
Date: Wed, 8 Aug 2007 01:37:09 -0400
To: "Lukas Kahwe Smith" <mls@pooteeweet.org>
Cc: "Larry Garfield" <larry@garfieldtech.com>, internals@lists.php.net
In-Reply-To: <46B94F8C.9030105@pooteeweet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <87E4F8AF-06DE-4FCC-AD1B-83E932A5E180@prohost.org>
	 <46B41A47.1080902@lsces.co.uk> <46B81302.1060403@lsces.co.uk>
	 <200708072345.58330.larry@garfieldtech.com>
	 <46B94F8C.9030105@pooteeweet.org>
Subject: Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
From: denials@gmail.com ("Dan Scott")

On 08/08/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
> Larry Garfield wrote:
> > 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?
>
> > 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.
>
> No, the idea is that there is a common set of methods and a common
> infrastructure to support those. However every driver is free to
> implement driver specific things and prefix those methods with the
> driver name. So in theory all the RDBMS specific goodies in all of the
> native drivers can also go into PDO.

Right. And Wez posted this (partially in reply to Lester's almost
identical hysterics at that time) on this very list ages ago
(http://news.php.net/php.internals/14937 - Feb 14, 2005, to be exact):

BEGIN QUOTE:
Drivers are free(*) to implement driver specific methods on the PDO
and PDOStatement objects, provided they are "namespaced"

eg:

$db->mysqlDoSomething()

would be a mysql driver specific feature.

More generic attributes can be accessed or set via the get/setAttribute methods.

(*) while they are "free" to do so, it's better to discuss the feature
first to see if it can be made into a more generic feature of PDO
itself
END QUOTE

So can we _please_ move on, Lester? If someone who cares about
Firebird wants to beef up the PDO_Firebird driver with all kinds of
Firebird-specific features, the answer is still the same as it was
almost two and a half years ago: the PHP project humbly awaits that
person's patch.

-- 
Dan Scott
Laurentian University