On Tue, 15 Feb 2005 17:24:05 +0100, Ard Biesheuvel <[EMAIL PROTECTED]> wrote: > Hi everyone, long time no post!
Welcome back Ard :) > What would be a reasonable deadline for this (in relation to 5.1) ? 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 are not that drastic, and the caller_frees change to get_col() should even make you happier. > 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. > - 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. > - 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. There are limits on the amount of work that can be done in one iteration of an opensource free-time-only project. 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. > 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. I don't have anything against firebird, it's just that I've only ever met one smart person that uses it (Ard :). If firebird was mission-critical for PHP, I'm sure we'd have heard from a lot more firebird users before now. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
