Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Please test PDO »

Please test PDO

php.internals

Wez Furlong

21 years ago
It's the weekend, time for relaxation and recreational hacking. The perfect opportunity to give PDO a whirl :-) Please *do* try it out soon as you can; with PHP 5.1 beta due on the first of March, it's really important to make sure that we don't have any "brown-paper-bag" bugs sooner rather than later. If you pass up on this round of testing, and then you find a bug in PDO in PHP 5.1, it's your fault. :-) Let's try to make 5.1 as "gold" as we can, --Wez.

Andi Gutmans

21 years ago
Yes, I'd like to second that. I'm still planning to release a beta in the beginning of March. Make sure you bring up any serious issues which would prevent that and/or need resolving first. Don't forget it's a beta so it doesn't have to be as perfect as an RC. Andi At 07:55 PM 2/11/2005 -0500, Wez Furlong wrote:

Ryan King

21 years ago
On Feb 11, 2005, at 4:55 PM, Wez Furlong wrote:
> It's the weekend, time for relaxation and recreational hacking. > The perfect opportunity to give PDO a whirl :-) > > Please *do* try it out soon as you can; with PHP 5.1 beta due on the > first of March, it's really important to make sure that we don't have > any "brown-paper-bag" bugs sooner rather than later. > > If you pass up on this round of testing, and then you find a bug in > PDO in PHP 5.1, it's your fault. :-) > > Let's try to make 5.1 as "gold" as we can, >
Would it be worthwhile to test PDO with 5.0.3? Or is it even possible. I'd like to help, but I was wondering whether I need to upgrade to 5.1 first. -ryan
-- http://theryanking.com/blog

Wez Furlong

21 years ago
Yes, PDO works with PHP 5.0.3, and we are indeed asking people to try it out with 5.0.3. If you're using OSX though, you'll probably have problems; PHP 5.0.3 appears to be broken on OSX. Just for you (well, not really, but I did do it in response to your mail :-), I've put together a guide on how to build PDO on OSX with the current stable snapshot of PHP (which will be PHP 5.0.4). I've tried this myself and it worked for me (tm). http://netevil.org/node.php?nid=202 While you have to build PHP yourself, you don't have to replace your existing installation (unless you want to). Good luck :) --Wez. On Fri, 11 Feb 2005 20:40:05 -0800, Ryan King <ryansking@mac.com> wrote:

Lester Caine

21 years ago
Wez Furlong wrote:
> It's the weekend, time for relaxation and recreational hacking. > The perfect opportunity to give PDO a whirl :-)
Wez I have had a look at PDO, but for many of us it is just a step BACK to the bad old days. ADOdb is well established and works. If you use the accelerator module then it can be very fast. WHY couldn't John have been helped to convert it to a more integrated package when he tried to get help from this list, which would allow upgrades to MANY systems without major re-writing of their code bases? OK many base functions will do the same job, but there is several years of development in the extensions to ADOdb, all of which would need to be re-done to switch to PDO - which is only recreating some of the functionality of the ADOdb drivers.
-- Lester Caine ----------------------------- L.S.Caine Electronic Services

Wez Furlong

21 years ago
You're missing the point. PDO isn't a replacement for ADOdb, it's a future replacement for ext/mysql, ext/pgsql, ext/oci8, ext/odbc, etc. etc. etc. If you want a database abstraction layer, stick with ADOdb and let John adapt that to run on top of PDO. WHY can't you be bothered to read the resources I've pointed you all at, where I explain this? --Wez. On Sat, 12 Feb 2005 07:51:13 +0000, Lester Caine

Lester Caine

21 years ago
Wez Furlong wrote:
> You're missing the point.
No *YOU* are missing the point. ADOdb is a well established abstraction layer. There have been many other attempts to provide the same facilities ( e.g PearDB ) and they are all playing catchup. ADOdb tries to assist by mapping functions so that people can move between these different layers without difficulty. (It has a Pear 'personality') JOHN has been trying to address the problem of speed of the core generic functions - which is the area that PDO is ALSO addressing.
> If you want a database abstraction layer, stick with ADOdb and let > John adapt that to run on top of PDO.
GERRRR!!!!!! WHY BOTHER !!!! Can't we pull together and push towards a SINGLE standard abstraction layer, rather than seemingly playing with bits and creating MORE work adapting perfectly stable code.
> WHY can't you be bothered to read the resources I've pointed you all > at, where I explain this?
Because *I* am trying to open the debate as to why we are forcing more modules into PHP that do not seem to have been fully thought out. If the effort put into PDO had been directed to the core of ADOdb we would HAVE all the functionality of PDO - WITH the remaining problems being addressed as well and a path to generic database generation. Instead work has now got to go into 35 drivers in ADOdb as well as the core library *IF* PDO is to be used. Until PDO has all the same drivers - ADOdb would become a mess, so there is little incentive to start changing, and to be honest, you would have to PROVE that PDO is as fast as the raw database drivers to warrant a change from them. You are hassling us to test PDO - I am saying hang on - what are we testing and is it the right approach anyway? WHY do people want cross engine support, so they can move code seamlessly between engines when the customer insists that 'X' is the only engine they will use. PDO is NOT addressing that problem. Your SQL code will still be engine specific, and the bulk of the changes will be in that area. So people need to be aware of *ALL* the limitations of PDO before they spend too much time going down a potential dead end! At the present time PDO is not suitable for me and just seems to be a waste of expertise that could be directed to something much more useful such as improving the core performance of ADOdb :(
-- Lester Caine ----------------------------- L.S.Caine Electronic Services

Wez Furlong

21 years ago
I'm sorry, you're right and we're all wrong. All of us. We, the stupid core developers of PHP, have been, for more than 2 years off-and-on, discussing the wrong solution to the problem. How could we be so blind? Aren't we dumb? We are mistaken that the C code is inconsistent and needs fixing. We're wrong to want to make it better. We're wrong to also want to make it more uniform. yes, yes, yes, we should stick with the current state of our database extensions.... because a third party abstraction layer that uses them would need to be rewritten. Excuse me while I remove PDO from CVS. NOT!!! On Sat, 12 Feb 2005 09:07:29 +0000, Lester Caine
> Until PDO has all the same drivers - ADOdb would become a mess, so there > is little incentive to start changing, and to be honest, you would have > to PROVE that PDO is as fast as the raw database drivers to warrant a > change from them.
Right. Try it. It's faster than adodb, I assure you. It's the as fast as the raw database drivers, because... you'll love, this, really you will..... PDO drivers *are* raw database drivers! wow! Aren't you glad that you went and read up on the facts before making a fool of yourself now??
> At the present time PDO is not suitable for me and just seems to be a > waste of expertise that could be directed to something much more useful > such as improving the core performance of ADOdb :(
OK, so don't use it. But *please* read up on the facts before spreading FUD. --Wez.

Lester Caine

21 years ago
Wez Furlong wrote:
>>Until PDO has all the same drivers - ADOdb would become a mess, so there >>is little incentive to start changing, and to be honest, you would have >>to PROVE that PDO is as fast as the raw database drivers to warrant a >>change from them. > > Right. Try it. It's faster than adodb, I assure you. > It's the as fast as the raw database drivers, because... you'll love, > this, really you will..... PDO drivers *are* raw database drivers! > wow! > Aren't you glad that you went and read up on the facts before making a > fool of yourself now??
I don't see that I am making a fool of myself? You have just answered the question. PDO is as fast as the native drivers! But it does not have all the extensions that are specific to each? So YES on it's own it will be faster than ADOdb - I don't have an argument with that - BUT it would be a backwards step to switch to it, because ADOdb picks up the engine specific facilities where possible, and provides emulation where not, so the subset that PDO supplies causes problems.
>>At the present time PDO is not suitable for me and just seems to be a >>waste of expertise that could be directed to something much more useful >>such as improving the core performance of ADOdb :( > > OK, so don't use it. But *please* read up on the facts before spreading FUD.
What FUD. PDO is a generic subset of the facilities required to access databases. If you need access to an engine specific function, then you still need the native driver as well? It's not a replacement for ADOdb, but at the same time, it's not suitable to use in place of the native drivers IN ADOdb - as yet. I'm just establishing the facts <shrug>
-- Lester Caine ----------------------------- L.S.Caine Electronic Services

Wez Furlong

21 years ago
On Sat, 12 Feb 2005 09:43:52 +0000, Lester Caine <lester@lsces.co.uk> wrote:
> I don't see that I am making a fool of myself?
Just about everyone I've met would feel at least embarrased if not downright foolish if they had done what you have just done, particularly given the number of people subscribed to this list, worldwide. *Go and read, at least, the OTN article.* Read all the links I've posted here over the last couple of days. Educate yourself before mouthing off; it's painfully obvious that you don't know what you're talking about; even worse is your refusal to read up on the subject. I'm not wasting any more of my time responding to your mails. --Wez.

Derick Rethans

21 years ago
On Sat, 12 Feb 2005, Lester Caine wrote:
> Wez Furlong wrote: > > ADOdb is a well established abstraction layer.
And there are others too: pear:db, mdb, metabase...
> > If you want a database abstraction layer, stick with ADOdb and let > > John adapt that to run on top of PDO. > > GERRRR!!!!!! > WHY BOTHER !!!! > Can't we pull together and push towards a SINGLE standard abstraction > layer, rather than seemingly playing with bits and creating MORE work > adapting perfectly stable code.
1. ADOdb has *nothing* to do with the PHP project 2. Some people don't need bloated libraries as ADOdb and still want to have one single unified interface to databases - THAT is what PDO is for: raw access.
> > WHY can't you be bothered to read the resources I've pointed you all > > at, where I explain this? > > Because *I* am trying to open the debate as to why we are forcing more > modules into PHP that do not seem to have been fully thought out.
How do you know it wasn't thought out? Were you there at the PDO meeting where most PHP's DB maintainers where?
> If the > effort put into PDO had been directed to the core of ADOdb we would HAVE > all the functionality of PDO - WITH the remaining problems being > addressed as well and a path to generic database generation. Instead > work has now got to go into 35 drivers in ADOdb as well as the core > library *IF* PDO is to be used.
Again, ADOdb is a PHP USERLAND solution, PDO is not. PDO is C, PDO is no bloated OO, PDO is fast.
> Your SQL code will still be engine > specific, and the bulk of the changes will be in that area. So people > need to be aware of *ALL* the limitations of PDO before they spend too > much time going down a potential dead end!
Sure, SQL needs to be changed between some engines but that is not the point of PDO as Wez already said a couple of times. PDO is providing a single unified API to database extensions.
> At the present time PDO is not suitable for me and just seems to be a > waste of expertise that could be directed to something much more useful > such as improving the core performance of ADOdb :(
Feel free, I don't care what you want to use - if you don't care about PDO, fine with me, good luck with ADOdb. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Lester Caine

21 years ago
Derick Rethans wrote:
> 1. ADOdb has *nothing* to do with the PHP project
It would not exist without it. No reason why it could not be part.
> 2. Some people don't need bloated libraries as ADOdb and still want to > have one single unified interface to databases - THAT is what PDO is > for: raw access.
Yes ADOdb is large, and that is part of the point. The core needs help from PHP to become lean, and then the extensions are just bolt-ons to a lean core. PDO should be that core, but I'm not seeing that at the moment. I'm seeing 'BDE' all over again. An attempt at a flat world view of databases that eventually died because it lost all abbility to also surface the strengths of the engines it was accessing.
> Again, ADOdb is a PHP USERLAND solution, PDO is not. PDO is C, PDO is no > bloated OO, PDO is fast.
ADOdb has a C accelerator that would benefit from the same sort of work that has been put into PDO - it's an existing project.
> Feel free, I don't care what you want to use - if you don't care about > PDO, fine with me, good luck with ADOdb.
My particular problem is mapping the SQL scripts between engines. That requires access to functions that PDO - I now learn - is not planned to provide. So *PLEASE* remember telling us what something will NOT do is as important as pushing what it does. Wez has already said what he does not plan to do with PDO - and that causes problems switching the next layer applications TO it. So we still need to plug that hole - PDO will not do it :(
-- Lester Caine ----------------------------- L.S.Caine Electronic Services

George Schlossnagle

21 years ago
On Feb 12, 2005, at 5:01 AM, Lester Caine wrote:
> Derick Rethans wrote: > >> 1. ADOdb has *nothing* to do with the PHP project > It would not exist without it. > No reason why it could not be part.
Plenty of things couldn't exist without PHP. That doesn't mean that PHP needs to hold still for their sake, or have it's development beholden to their creators. But even if we lived in some Bizaro world where such was the case, there's still the point that John sees no issues with PDO and ADODB coexisting. He's clearly been aware of PDOs path for quite a while now. Here was John's viewpoint on PDO seven months ago: http://phplens.com/phpeverywhere/?q=node/view/1 It's been stated a couple times, but I'll throw my voice into this since you seem to have not captured the meaning of other people's messages: PDO and ADODB have different goals. If you don't like PDO, don't use it. If you don't want to test PDO, don't test it. If John doesn't want to include PDO support in ADODB, that's his prerogative. That wasn't the path he proposed, but if he changes his mind to that extent, then that's a problem between you and him, not between you and us. George

Rasmus Lerdorf

21 years ago
Lester Caine wrote:
> Wez Furlong wrote: > >> You're missing the point. > > > No *YOU* are missing the point.
Lester, have you bothered to read the code at all? PDO is to databases what SAPI is to web servers. It is a layer in the guts of PHP that will one day make it much easier to maintain and add new database drivers. It has absolutely nothing to do with user-space database abstraction like what ADOdb provides and is completely orthogonal. The reason Wez would like you to test it is because in the future some databases will only be accessible via PDO, so unless you are planning on writing user-space protocol-level socket handling code into ADOdb, you are going to need to use it in order to speak to those databases. This doesn't mean that the current database extensions are going away, but PDO aims to provide a much simpler way for database vendors to provide PHP support without having to struggle with all the low-level PHP internals required today. I deal with quite a few database-like things that don't speak nicely with PHP today, and I am looking forward to the day where via PDO I can write native PHP support for these in an hour or two instead of having to set aside a week for it. -Rasmus

Andi Gutmans

21 years ago
Yes I very much agree with Wez. PHP has long suffered from poor implementations of some of the DB extensions and good implementations of others. PDO is a good opportunity to unify the extensions and have a common code base so that bug fixes propagate to all extensions (at least in most cases). Of course there are also additional benefits to PDO. I think PDO is very important for the future and stability of PHP and I don't think projects like ADOdb are replaced by it. But yes, I think in the long-term ADOdb will probably be better off migrating to PDO for it's underlying DB connections. It would probably improve it's maintainability and stability. Andi At 03:12 AM 2/12/2005 -0500, Wez Furlong wrote:

Christian Schneider

21 years ago
Andi Gutmans wrote:
> PHP has long suffered from poor implementations of some of the DB > extensions and good implementations of others. PDO is a good opportunity > to unify the extensions and have a common code base so that bug fixes
Excuse my ignorance, maybe I missed the answer to Lester's question: What's the proposed way of accessing the DB-specific functionality once PDO is there? Is everything available through SQL statements or get/srcAttribute? After a first look at the MySQL functions my guess is that that's the case. At least I can't see anything I need which I couldn't reach that way. Please enlighten me, - Chris

Wez Furlong

21 years ago
Depends on the functionality. 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. -Wez. On Mon, 14 Feb 2005 23:34:21 +0100, Christian Schneider <cschneid@cschneid.com> wrote:

Alan Knowles

21 years ago
It would be usefull if there was a shared struct for this in pdo core: eg. (in /ext/pdo/php_pdo_drivers_extras.h) (mysql_do_something_ptr *) mysql_do_something(pdo_stmt_t *,char * an_argument) pdo_driver_extras_mysql { mysql_do_something_ptr *mysql_do_something, .... } So that other extensions can call these methods without having to link to the specific backend, or kludge through call_user_function or something) Regards Alan Wez Furlong wrote:

Wez Furlong

21 years ago
That's also something of a hack (PDO core doesn't and shouldn't know about mysql specific features). It's better to have a generic mechanism for this, such as the "interfaces" idea I mentioned a couple of years back. I don't think there will be time to wedge that into 5.1 though :-/ --Wez. On Tue, 15 Feb 2005 08:47:09 +0800, Alan Knowles <alan@akbkhome.com> wrote:

Lester Caine

21 years ago
Christian Schneider wrote:
> Andi Gutmans wrote: > >> PHP has long suffered from poor implementations of some of the DB >> extensions and good implementations of others. PDO is a good >> opportunity to unify the extensions and have a common code base so >> that bug fixes > > Excuse my ignorance, maybe I missed the answer to Lester's question: > What's the proposed way of accessing the DB-specific functionality once > PDO is there? Is everything available through SQL statements or > get/srcAttribute? After a first look at the MySQL functions my guess is > that that's the case. At least I can't see anything I need which I > couldn't reach that way. > > Please enlighten me,
THAT is the nail I was missing. Firebird has a number of functions that are not managed via SQL, and require the 'services' interface. In addition, while the Transaction interface can be compressed into the straight jacket that PDO defines, it would be nice to commitRetaining, but that is something that can be addressed once the need to run the native driver as well as been removed.
-- Lester Caine ----------------------------- L.S.Caine Electronic Services

Lukas Smith

21 years ago
Lester Caine wrote:
> In addition, while the Transaction interface can be compressed into the > straight jacket that PDO defines, it would be nice to commitRetaining, > but that is something that can be addressed once the need to run the > native driver as well as been removed.
We did discuss the topic of how to handle transactions in depth (especially in the context of firebird) but decided that we should keep the standard transaction interface as is in order to not confuse the bulk of the users. I really like Wez approach here (maybe cause I took the same approach in MDB2): Give a solid common denominator that is realistically achieveable and doesnt cause too much confusion to the userbase at large, while allowing every driver to add specific functionality. It is however key to still talk things through between the driver developers because certain non portable features may still be portable across a significant subset of RDBMS. Obviously there are some tough calls. Like the fact that transactions are not universally supported and things like last insert id. However I think that these calls have been A+ so far in this regard .. regards, Lukas

George Schlossnagle

21 years ago
On Feb 15, 2005, at 2:57 AM, Lester Caine wrote:
> Christian Schneider wrote: > >> Andi Gutmans wrote: >>> PHP has long suffered from poor implementations of some of the DB >>> extensions and good implementations of others. PDO is a good >>> opportunity to unify the extensions and have a common code base so >>> that bug fixes >> Excuse my ignorance, maybe I missed the answer to Lester's question: >> What's the proposed way of accessing the DB-specific functionality >> once PDO is there? Is everything available through SQL statements or >> get/srcAttribute? After a first look at the MySQL functions my guess >> is that that's the case. At least I can't see anything I need which I >> couldn't reach that way. >> Please enlighten me, > > THAT is the nail I was missing. Firebird has a number of functions > that are not managed via SQL, and require the 'services' interface.
That question has been answered at least twice in this thread, with specific examples given regarding mysql (or at least using mysql as the example). George

Lester Caine

21 years ago
George Schlossnagle wrote:
>>>> PHP has long suffered from poor implementations of some of the DB >>>> extensions and good implementations of others. PDO is a good >>>> opportunity to unify the extensions and have a common code base so >>>> that bug fixes >>> >>> Excuse my ignorance, maybe I missed the answer to Lester's question: >>> What's the proposed way of accessing the DB-specific functionality >>> once PDO is there? Is everything available through SQL statements or >>> get/srcAttribute? After a first look at the MySQL functions my guess >>> is that that's the case. At least I can't see anything I need which I >>> couldn't reach that way. >>> Please enlighten me, >> >> THAT is the nail I was missing. Firebird has a number of functions >> that are not managed via SQL, and require the 'services' interface. > > That question has been answered at least twice in this thread, with > specific examples given regarding mysql (or at least using mysql as the > example).
PLEASE - I am trying to be as constructive as I can. Until the php_firebird driver code is brought up to date with the latest core code I can't get much of what IS available working, so I am looking to what functions still need the php_interbase driver running in parallel to see what can be done about them. What is needed fairly soon is a hook where we can document these engine specific details and perhaps give pointers as to how missing functionality can be got around. This will at least then provide an indication as to what still needs to be done on a driver by driver basis, and more important, somewhere we can look for hints when trying to carry out those same functions on other engines. My previous messages were badly worded and were not explaining things very well. I got panicked again by the 'replacing existing drivers' comments which is still a concern given the work that is currently being done on changes to most of the database engines and in my case Firebird and I hope that these drivers are not simply side-tracked - until PDO *IS* in a position to provide the same functionality - which is still some way off yet? Maintaining backwards compatibility is all very well, but if you can't access the nice new stuff .... I apologise if my attitude has annoyed but I am not in the slightest embarrassed ;) as I still think that lessons need to be learnt from the existing methods of doing things to provide an excellent generic solution. Us old timers get used to the crutches, so when someone takes them away we start drowning :)
-- Lester Caine ----------------------------- L.S.Caine Electronic Services

Ard Biesheuvel

21 years ago
Hi everyone, long time no post! Wow, a lot has happened to PDO while I was looking the other way for a minute. I hope I will soon find the time to bring PDO_FIREBIRD up to date with all the recent changes. What would be a reasonable deadline for this (in relation to 5.1) ? Lester Caine wrote:
> PLEASE - I am trying to be as constructive as I can. Until the > php_firebird driver code is brought up to date with the latest core code > I can't get much of what IS available working, so I am looking to what > functions still need the php_interbase driver running in parallel to see > what can be done about them. What is needed fairly soon is a hook where > we can document these engine specific details and perhaps give pointers > as to how missing functionality can be got around. This will at least > then provide an indication as to what still needs to be done on a driver > by driver basis, and more important, somewhere we can look for hints > when trying to carry out those same functions on other engines. >
As I've said before in our discussions about PDO, I am not very happy about the apparent 'impedance mismatch' between Firebird and PDO. If PDO is turning out to be a least-common-denominator solution like most abstraction layers, it's going to be impossible to ever provide the features that the original Firebird/Interbase driver does. 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; - running concurrent transactions off the same connection; - named results; - the whole service API (inquiries about the server/database/users etc.); - event handling; So if the intention is to ultimately replace the Firebird/Interbase driver with a PDO one, a lot of work has to be done. And PDO *will* have to be changed to allow for the more exotic features of Firebird.
-- Ard

Wez Furlong

21 years ago
On Tue, 15 Feb 2005 17:24:05 +0100, Ard Biesheuvel <abies@php.net> 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.

l0t3k

21 years ago
Wez, do you know if some resources for ole-db ? when i was silly enough to try and write my own abstraction layer, that was the one that got away. if i had some code/samples/documentation, i'd try my hand at supporting it.... "Wez Furlong" <kingwez@gmail.com> wrote in message news:4e89b4260502151221b7cddc0@mail.gmail.com...

Ard Biesheuvel

21 years ago
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

Antony Dovgal

21 years ago
On Fri, 11 Feb 2005 19:55:09 -0500 Wez Furlong <kingwez@gmail.com> wrote:
> It's the weekend, time for relaxation and recreational hacking. > The perfect opportunity to give PDO a whirl :-) > > Please *do* try it out soon as you can; with PHP 5.1 beta due on the > first of March, it's really important to make sure that we don't have > any "brown-paper-bag" bugs sooner rather than later.
Wez, PDO + PDO_OCI seems to be rather usable, BUT: I got segfault on shutdown everytime. The gdb bt looks senseless to me: Program received signal SIGSEGV, Segmentation fault. 0xb799ade0 in ?? () (gdb) bt #0 0xb799ade0 in ?? () #1 0x081d9d3f in main (argc=2, argv=0xbffff874) at /home/dev/php-src/sapi/cli/php_cli.c:1060 #2 0x420157a4 in __libc_start_main () from /lib/tls/libc.so.6 I tried to compile PDO itself as both static & dynamic, but I still get the very same segfault with the very same senseless bt. Is it a known bug or am I missing something ? Also, I failed to compile PDO_OCI statically, as it complains that PDO must be loaded first (I thought module loading order has been fixed in HEAD, no?).
-- Wbr, Antony Dovgal aka tony2001

Wez Furlong

21 years ago
Thanks Tony, On Mon, 14 Feb 2005 15:52:11 +0300, Antony Dovgal <antony@zend.com> wrote:
> Wez, PDO + PDO_OCI seems to be rather usable, BUT: > I got segfault on shutdown everytime.
Hmm, I found that I had to set the db and stmt handles to null prior to exiting the script to avoid a crash (that good old engine shut down bug, where it unloads the code before calling the destructors!) Not sure if this is the same problem or not, but it's worth a try.
> Also, I failed to compile PDO_OCI statically, as it complains that PDO > must be loaded first (I thought module loading order has been fixed > in HEAD, no?).
It has, but I deliberately removed the deps stuff while making the PECL releases, as the m4 macro for that is not in 5.0.3. You can either turn it on in your tree (look for EXTENSION_DEP in the config.m4), or manually fix the ordering by editing main/internal_functions*.c (http://netevil.org/node.php?nid=202 has some info on this). --Wez.

Antony Dovgal

21 years ago
On Mon, 14 Feb 2005 10:29:39 -0500 Wez Furlong <kingwez@gmail.com> wrote:
> Thanks Tony, > > On Mon, 14 Feb 2005 15:52:11 +0300, Antony Dovgal <antony@zend.com> > wrote: > > Wez, PDO + PDO_OCI seems to be rather usable, BUT: > > I got segfault on shutdown everytime. > > Hmm, I found that I had to set the db and stmt handles to null prior > to exiting the script to avoid a crash (that good old engine shut down > bug, where it unloads the code before calling the destructors!) > > Not sure if this is the same problem or not, but it's worth a try.
Nope, this is something different.. Could you look into it, plz?
> > Also, I failed to compile PDO_OCI statically, as it complains that > > PDO must be loaded first (I thought module loading order has been > > fixed in HEAD, no?). > > It has, but I deliberately removed the deps stuff while making the > PECL releases, as the m4 macro for that is not in 5.0.3. > > You can either turn it on in your tree (look for EXTENSION_DEP in the > config.m4), or manually fix the ordering by editing > main/internal_functions*.c (http://netevil.org/node.php?nid=202 has > some info on this).
Ok, got it. Will try it later.
-- Wbr, Antony Dovgal aka tony2001 antony@zend.com

Wez Furlong

21 years ago
On Tue, 15 Feb 2005 01:16:58 +0300, Antony Dovgal <antony@zend.com> wrote:
> > > Wez, PDO + PDO_OCI seems to be rather usable, BUT: > > > I got segfault on shutdown everytime.
> Nope, this is something different.. > Could you look into it, plz?
Backtrace? --Wez.

Wez Furlong

21 years ago
On Mon, 14 Feb 2005 17:32:42 -0500, Wez Furlong <kingwez@gmail.com> wrote:
> On Tue, 15 Feb 2005 01:16:58 +0300, Antony Dovgal <antony@zend.com> wrote: > > > > Wez, PDO + PDO_OCI seems to be rather usable, BUT: > > > > I got segfault on shutdown everytime. > > > Nope, this is something different.. > > Could you look into it, plz? > Backtrace?
And/or reproducing script; thanks :) --Wez.

Antony Dovgal

21 years ago
On Mon, 14 Feb 2005 17:32:42 -0500 Wez Furlong <kingwez@gmail.com> wrote:
> On Tue, 15 Feb 2005 01:16:58 +0300, Antony Dovgal <antony@zend.com> > wrote: > > > > Wez, PDO + PDO_OCI seems to be rather usable, BUT: > > > > I got segfault on shutdown everytime. > > > Nope, this is something different.. > > Could you look into it, plz? > > Backtrace?
the same: Program received signal SIGSEGV, Segmentation fault. 0xb799ade0 in ?? () (gdb) bt #0 0xb799ade0 in ?? () #1 0x081d9d3f in main (argc=2, argv=0xbffff874) at /home/dev/php-src/sapi/cli/php_cli.c:1060 #2 0x420157a4 in __libc_start_main () from /lib/tls/libc.so.6 (gdb) The program is running. Exit anyway? (y or n) y the code: <?php /* $dbase, $user & $password are valid. I even got the query results after connecting, but it still segfaults on shutdown. */ $db = new PDO("oci:dbname=$dbase",$user,$password); $db = null; ?> PDO is compiled statically, PDO_OCI - as shared module. I'm using today's HEAD. Oracle9i Enterprise Edition Release 9.2.0.1.0 (don't think it can cause it). If you have any other questions - just ask =)
-- Wbr, Antony Dovgal aka tony2001 antony@zend.com