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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
