Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14997
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <20050215235906.80788.qmail@lists.php.net>
To: internals@lists.php.net
Date: Wed, 16 Feb 2005 00:59:06 +0100
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
References: <4e89b4260502111655215a94e8@mail.gmail.com>	<20050212074627.64626.qmail@lists.php.net>	<5.1.0.14.2.20050214140808.03860a60@localhost>	<20050214223422.17886.qmail@lists.php.net>	<20050215075252.53314.qmail@lists.php.net>	<320bcc2f994258af3ef8c8c49d6b158e@omniti.com>	<20050215152603.22435.qmail@lists.php.net>	<20050215162406.55618.qmail@lists.php.net> <4e89b4260502151221b7cddc0@mail.gmail.com>
In-Reply-To: <4e89b4260502151221b7cddc0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Please test PDO
From: abies@php.net (Ard Biesheuvel)

Wez Furlong wrote:

> 5.1 beta is scheduled for March 1st, and we'll follow that with the
> usual RC process.  I think you have a little bit of time; the changes

OK.

>>For instance (these issues have been pointed out by me before):
>>- Firebird has transactions over multiple connections [no JOINs between
>>databases, but atomicity/consistency across multiple DBs]. There's no
>>way this will ever be supported in PDO due to the way it was designed;
> 
> You can/should/must implement this as a firebird specific method, as
> no other database has this feature.
> 

[Excuse my ignorance: haven't worked on PHP for a while] Does this mean 
the DB-specific derivations of the PDO classes can/will have methods no 
other drivers support? Something like 
PDO_FIREBIRD::startMultiple($db1,$db2)?

>>- the whole service API (inquiries about the server/database/users etc.);
> 
> Dan and myself discussed this a couple of weeks back (and I noticed
> that he's mentioned it here in another thread).  The
> service/administration side of things is a different interface doesn't
> belong as a part of the database handle class.
> There is room for it, just not in this iteration.
> 

OK, clear. But those features are as non-portable as they'll ever get => 
every database has them, but in a different way.

>>- running concurrent transactions off the same connection;
>>- event handling;
>>- named results;
> 
>>So if the intention is to ultimately replace the Firebird/Interbase
>>driver with a PDO one, a lot of work has to be done.
> 
> Yes, but not all at once.
> 

I would opt for the least painful solution possible, and that would be 
to allow the 'native' functions to be used through PDO in some way if no 
solution has been implemented specifically. Maybe we could discuss this 
some more sometime.

> There are limits on the amount of work that can be done in one
> iteration of an opensource free-time-only project.
> 

Tell me about it!

> Right now, the PDO class is geared up for providing access to your data.
> Pretty much everything else that has been quoted as bad or missing
> features are either fringe features or fringe use cases, compared to
> the typical uses of PHP: getting data out of the database and showing
> it on a web page.
> 

Of course. But in the case of Firebird, these fringe features - as you 
call them - may well have been the reason someone uses Firebird in the 
first place. The whole reason I ever got involved with developing 
PHP/Firebird is because the whole multiple transaction thing had never 
been implemented in PHP, and I needed it for a project.

>>And PDO *will* have
>>to be changed to allow for the more exotic features of Firebird.
> 
> Nope, the firebird driver can implement them as driver specific features.
> They're so exotic that no other database implements them; it doesn't
> make sense to redesign just for firebird.
> 

OK, as long as that is possible, I'm fine with it.

-- 
Ard