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.
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/)
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
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.
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
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.
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 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.
- ADOdb has nothing to do with the PHP project
- 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
Derick Rethans wrote:
- ADOdb has nothing to do with the PHP project
It would not exist without it.
No reason why it could not be part.
- 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
Derick Rethans wrote:
- 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
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.
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
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.
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
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
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.
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, 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, 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.
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