# Please test PDO - Thread: https://externals.io/message/14845 - Original archive: https://news-web.php.net/php.internals/14845 - Started by Wez Furlong on 2005-02-12T00:55:09+00:00 - Messages: 33 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/14845.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #14845 — Wez Furlong — 2005-02-12T00:55:09+00:00 URL: https://externals.io/message/14845#14845 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. --- ## #14846 — Andi Gutmans — 2005-02-12T01:12:35+00:00 URL: https://externals.io/message/14845#14846 · In reply to: #14845 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: >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. > >-- >PECL development discussion Mailing List (http://pecl.php.net/) --- ## #14849 — Ryan King — 2005-02-12T04:40:05+00:00 URL: https://externals.io/message/14845#14849 · In reply to: #14845 > 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 --- ## #14852 — Lester Caine — 2005-02-12T07:51:13+00:00 URL: https://externals.io/message/14845#14852 · In reply to: #14845 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 --- ## #14854 — Wez Furlong — 2005-02-12T08:12:32+00:00 URL: https://externals.io/message/14845#14854 · In reply to: #14852 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 > 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. --- ## #14856 — Wez Furlong — 2005-02-12T08:45:11+00:00 URL: https://externals.io/message/14845#14856 · In reply to: #14849 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. > 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. --- ## #14858 — Lester Caine — 2005-02-12T09:07:29+00:00 URL: https://externals.io/message/14845#14858 · In reply to: #14854 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 --- ## #14861 — Derick Rethans — 2005-02-12T09:22:49+00:00 URL: https://externals.io/message/14845#14861 · In reply to: #14858 > Wez Furlong wrote: > > ADOdb is a well established abstraction layer. And there are others too: pear:db, mdb, metabase... > > […] > > 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. > > […] > > 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 --- ## #14860 — Wez Furlong — 2005-02-12T09:23:09+00:00 URL: https://externals.io/message/14845#14860 · In reply to: #14858 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. --- ## #14862 — Rasmus Lerdorf — 2005-02-12T09:31:09+00:00 URL: https://externals.io/message/14845#14862 · In reply to: #14858 Lester Caine wrote: > Wez Furlong wrote: > > > […] > > > 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 --- ## #14863 — Lester Caine — 2005-02-12T09:43:52+00:00 URL: https://externals.io/message/14845#14863 · In reply to: #14860 Wez Furlong wrote: > > […] > > 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. > > […] > > 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 -- Lester Caine ----------------------------- L.S.Caine Electronic Services --- ## #14864 — Wez Furlong — 2005-02-12T09:53:49+00:00 URL: https://externals.io/message/14845#14864 · In reply to: #14863 > 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. --- ## #14865 — Lester Caine — 2005-02-12T10:01:44+00:00 URL: https://externals.io/message/14845#14865 · In reply to: #14861 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 --- ## #14888 — George Schlossnagle — 2005-02-13T02:23:07+00:00 URL: https://externals.io/message/14845#14888 · In reply to: #14865 > Derick Rethans wrote: > > > […] > 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 --- ## #14923 — Antony Dovgal — 2005-02-14T12:52:11+00:00 URL: https://externals.io/message/14845#14923 · In reply to: #14845 On Fri, 11 Feb 2005 19:55:09 -0500 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. 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 --- ## #14920 — Wez Furlong — 2005-02-14T15:29:39+00:00 URL: https://externals.io/message/14845#14920 · In reply to: #14923 Thanks Tony, > 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. --- ## #14933 — Antony Dovgal — 2005-02-14T22:16:58+00:00 URL: https://externals.io/message/14845#14933 · In reply to: #14920 On Mon, 14 Feb 2005 10:29:39 -0500 Wez Furlong wrote: > Thanks Tony, > > On Mon, 14 Feb 2005 15:52:11 +0300, Antony Dovgal > wrote: > > […] > > 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? > > […] > > 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 --- ## #14932 — Wez Furlong — 2005-02-14T22:32:42+00:00 URL: https://externals.io/message/14845#14932 · In reply to: #14933 > > […] > Nope, this is something different.. > Could you look into it, plz? Backtrace? --Wez. --- ## #14935 — Wez Furlong — 2005-02-14T22:35:22+00:00 URL: https://externals.io/message/14845#14935 · In reply to: #14932 > > > […] > > > […] > Backtrace? And/or reproducing script; thanks :) --Wez. --- ## #14938 — Antony Dovgal — 2005-02-14T22:35:50+00:00 URL: https://externals.io/message/14845#14938 · In reply to: #14932 On Mon, 14 Feb 2005 17:32:42 -0500 Wez Furlong wrote: > On Tue, 15 Feb 2005 01:16:58 +0300, Antony Dovgal > wrote: > > […] > > > […] > > 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: 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 --- ## #14937 — Wez Furlong — 2005-02-14T22:41:25+00:00 URL: https://externals.io/message/14845#14937 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 wrote: > 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. --- ## #14944 — Alan Knowles — 2005-02-15T00:47:09+00:00 URL: https://externals.io/message/14845#14944 · In reply to: #14937 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: >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 > wrote: > > > > […] --- ## #14947 — Wez Furlong — 2005-02-15T01:28:02+00:00 URL: https://externals.io/message/14845#14947 · In reply to: #14944 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. > 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: > > > […] --- ## #14984 — Wez Furlong — 2005-02-15T20:21:48+00:00 URL: https://externals.io/message/14845#14984 > 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. --- ## #14988 — l0t3k — 2005-02-15T21:24:39+00:00 URL: https://externals.io/message/14845#14988 · In reply to: #14984 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" wrote in message news:4e89b4260502151221b7cddc0@mail.gmail.com... > > > […] --- Next page: https://externals.io/message/14845.md?page=2