5.2.4RC1 Released

16 years ago by Ilia Alshanetsky — view source

unread

As promised two weeks ago, the 5.2.4RC1 was released today and the
sources for the release can be found here:

http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum:
43e28d2aa55b6c8bcd67da16e24b225a)

Windows binaries should become available in short order as well.

This release have been long in the making so the changelog is a bit
intimidating, so we definitely need a lot of testing for this
release. I would like to ask everyone to give this RC a shot and see
how it behaves with their code and hopefully not find any
regressions. If you do find any, please let us know. Now that RC1 is
out, I would like to ask all developers to refrain from making any
feature additions to 5.2.4 at this time and only apply bug fixes. I
am hoping to have RC2 released within 2 weeks from now and if it
proves to be stable move onto the final release a week from then. So,
if all goes well we should have 5.2.4 out within a month or less.

One exception to the rule I'd like to make known is Stas' ini system
patch, which I feel we should include, but that's still being
currently discussed. Aside from those, no feature additions, please.

Ilia Alshanetsky

16 years ago by Edin Kadribasic — view source

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The windows build is now ready and can be downloded from:

http://downloads.php.net/edink/php-5.2.4RC1-Win32.zip
http://downloads.php.net/edink/php-5.2.4RC1-win32-installer.msi
http://downloads.php.net/edink/pecl-5.2.4RC1-Win32.zip
http://downloads.php.net/edink/php-debug-pack-5.2.4RC1-Win32.zip

Edin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGsqgAoL7jghV9D6gRAlHnAJ4zqzKikiBgffzvQBQqLBsASJoa3wCgy+fR
bSR1MvfCW25LqASgYiELIpo=
=j3j0
-----END PGP SIGNATURE

16 years ago by Scott MacVicar — view source

unread

Edin,

Can you upgrade the bundled MySQL libraries so we can get #41350 fixed,
the code is already there it just needs the latest libraries on Windows.

Scott

Edin Kadribasic wrote:

The windows build is now ready and can be downloded from:

http://downloads.php.net/edink/php-5.2.4RC1-Win32.zip
http://downloads.php.net/edink/php-5.2.4RC1-win32-installer.msi
http://downloads.php.net/edink/pecl-5.2.4RC1-Win32.zip
http://downloads.php.net/edink/php-debug-pack-5.2.4RC1-Win32.zip

Edin

16 years ago by Antony Dovgal — view source

unread

Edin,

Can you upgrade the bundled MySQL libraries so we can get #41350 fixed,
the code is already there it just needs the latest libraries on Windows.

We also need the latest t1lib and libtidy on Windows.

--
Wbr,
Antony Dovgal

16 years ago by Uwe Schindler — view source

unread

Configuring on Solaris (2.10) no longer works, ist the old problem with
"test" that is more strict on solaris:

...
checking dynamic linker characteristics... solaris2.10 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no

Generating files
./configure: test: argument expected
pangaeaw@pansrv1:~/install/php-5.2.4RC1$

config.log does not show anything special:
...
configure:113510: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fPIC -DPIC conftest.cpp 1>&5
configure:113514: $? = 0
configure:113552: checking if c++ supports -c -o file.o
configure:113572: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -o out/conftest2.o conftest.cpp 1>&5
configure:113576: $? = 0
configure:113623: checking whether the c++ linker (/usr/ccs/bin/ld) supports
shared libraries
configure:113709: checking dynamic linker characteristics
configure:114283: checking how to hardcode library paths into programs
configure:114321: checking whether stripping libraries is possible

Uwe

Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany

From: Ilia Alshanetsky [mailto:ilia@prohost.org]
Sent: Friday, August 03, 2007 1:37 AM
To: PHP Internals
Subject: [PHP-DEV] 5.2.4RC1 Released

As promised two weeks ago, the 5.2.4RC1 was released today and the
sources for the release can be found here:

http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum:
43e28d2aa55b6c8bcd67da16e24b225a)

Windows binaries should become available in short order as well.

This release have been long in the making so the changelog is a bit
intimidating, so we definitely need a lot of testing for this
release. I would like to ask everyone to give this RC a shot and see
how it behaves with their code and hopefully not find any
regressions. If you do find any, please let us know. Now that RC1 is
out, I would like to ask all developers to refrain from making any
feature additions to 5.2.4 at this time and only apply bug fixes. I
am hoping to have RC2 released within 2 weeks from now and if it
proves to be stable move onto the final release a week from then. So,
if all goes well we should have 5.2.4 out within a month or less.

One exception to the rule I'd like to make known is Stas' ini system
patch, which I feel we should include, but that's still being
currently discussed. Aside from those, no feature additions, please.

Ilia Alshanetsky

16 years ago by Antony Dovgal — view source

unread

Configuring on Solaris (2.10) no longer works, ist the old problem with
"test" that is more strict on solaris:

...
checking dynamic linker characteristics... solaris2.10 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no

Generating files
./configure: test: argument expected
pangaeaw@pansrv1:~/install/php-5.2.4RC1$

Cannot reproduce this, configure went just fine on Solaris.
Can you please see on which line in configure script it complains?

The following two things are problematic:

@-operator before function names does not suppress warning messages
anymore? Whats wrong?
I got for example messages like "cannot open file..." even when it was
opened with @fopen(...).

Not reproducible either.
./sapi/cli/php -r 'fopen("aaaaa", "r");'

Warning: fopen(aaaaa): failed to open stream: No such file or directory in Command line code on line 1
./sapi/cli/php -r '@fopen("aaaaa", "r");'
<silence>

make test is broken:
pangaeaw@pansrv1:~/install/php-5.2.4RC1$ gmake test

Build complete.
Don't forget to run 'make test'.

/bin/sh: syntax error at line 1: `;' unexpected
gmake: [test] Error 2 (ignored)

Confirmed, Jani's configure.in tweaks do not work with broken shell on Solaris.
Jani, please take a look at it, it complains each time I try to use $(PHP_TEST_SHARED_EXTENSIONS).

--
Wbr,
Antony Dovgal

16 years ago by Uwe Schindler — view source

unread

Configuring on Solaris (2.10) no longer works, ist the old problem with
"test" that is more strict on solaris:

...
checking dynamic linker characteristics... solaris2.10 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no

Generating files
./configure: test: argument expected
pangaeaw@pansrv1:~/install/php-5.2.4RC1$

Cannot reproduce this, configure went just fine on Solaris.
Can you please see on which line in configure script it complains?

How can I find that out? Is there a debug parameter? Config.log does not
show anything.

Could it be that on your solaris system the default shell in /bin/sh is
"bash"?

The following two things are problematic:

@-operator before function names does not suppress warning messages
anymore? Whats wrong?
I got for example messages like "cannot open file..." even when it was
opened with @fopen(...).

Not reproducible either.
./sapi/cli/php -r 'fopen("aaaaa", "r");'

Warning: fopen(aaaaa): failed to open stream: No such file or directory in
Command line code on line 1
./sapi/cli/php -r '@fopen("aaaaa", "r");'
<silence>

You are right with CLI it works. But there seems to be a problem with INI
parsing. The web application that produced this error was started with an
overwritten "error_reporting" value running in Sun Java System Webserver
which worked correctly with 5.2.3:

Service fn="php5_execute" type="magnus-internal/x-httpd-php"
error_reporting="2039" allow_url_include="1"

Removing the error_reporting fixed the problem. Was there a change somewhere
that error_reporting with 2039 set by...

if (zend_alter_ini_entry(entry->param->name, strlen(entry->param->name)+1,
entry->param->value, strlen(entry->param->value),
PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE)==FAILURE) {
log_error(LOG_WARN, pblock_findval("fn", NSG(pb)), NSG(sn), NSG(rq),
"Cannot change php.ini key "%s" to "%s"", entry->param->name,
entry->param->value);
}

...may not work? Just for interest, I am sure that this NSAPI option was not
correct because it was a relict from former days.
I removed the wrong error reporting now, but it is interesting that the same
value worked before.

Uwe

16 years ago by Antony Dovgal — view source

unread

Cannot reproduce this, configure went just fine on Solaris.
Can you please see on which line in configure script it complains?

How can I find that out? Is there a debug parameter? Config.log does not
show anything.

Could it be that on your solaris system the default shell in /bin/sh is
"bash"?

It's definitely not bash (cause I have to run bash manually to get a usable shell).

ls -l /bin/sh

-r-xr-xr-x 4 root root 95320 Jul 30 2004 /bin/sh

You are right with CLI it works. But there seems to be a problem with INI
parsing. The web application that produced this error was started with an
overwritten "error_reporting" value running in Sun Java System Webserver
which worked correctly with 5.2.3:

Service fn="php5_execute" type="magnus-internal/x-httpd-php"
error_reporting="2039" allow_url_include="1"

This works just fine either:
./sapi/cli/php -d error_reporting=2039 -r 'error_reporting(2039); @fopen("aaaa", "r");

No idea how the sun webserver passes options to PHP, though.

--
Wbr,
Antony Dovgal

16 years ago by Uwe Schindler — view source

unread

Cannot reproduce this, configure went just fine on Solaris.
Can you please see on which line in configure script it complains?

How can I find that out? Is there a debug parameter? Config.log does not
show anything.

Could it be that on your solaris system the default shell in /bin/sh is
"bash"?

It's definitely not bash (cause I have to run bash manually to get a
usable shell).

ls -l /bin/sh

-r-xr-xr-x 4 root root 95320 Jul 30 2004 /bin/sh

pangaeaw@pansrv1:~/install/php-5.2.4RC1$ ls -l /bin/sh
lrwxrwxrwx 1 root root 13 Apr 13 10:40 /bin/sh ->
../../sbin/sh
pangaeaw@pansrv1:~/install/php-5.2.4RC1$ ls -l /sbin/sh
-r-xr-xr-x 1 root root 82468 Oct 18 2006 /sbin/sh

Until now, I have no error location. I think I will look into the changes in
configure.in and look for test calls and try to modify them.

Starting configure with sh -v did not work it only prints a few messages at
beginning but then switches to another shell (???). The problem is fixed if
you start configure with "bash configure". But it would be good to fix this.

You are right with CLI it works. But there seems to be a problem with
INI
parsing. The web application that produced this error was started with
an
overwritten "error_reporting" value running in Sun Java System Webserver
which worked correctly with 5.2.3:

Service fn="php5_execute" type="magnus-internal/x-httpd-php"
error_reporting="2039" allow_url_include="1"

This works just fine either:
./sapi/cli/php -d error_reporting=2039 -r 'error_reporting(2039);
@fopen("aaaa", "r");

No idea how the sun webserver passes options to PHP, though.

I looked into it:
The problem seems to be ZTS specific.
What we have:

First, the value looks correct in phpinfo().
Second setting the value to 6039 (which is the default from php.ini)
produces now a lot of more and very strange error messages when running
PHP scripts.

It seems that the webserver puts the value somewhere to a global place
because after that ALL PHP scripts print very strange things (even those
where this value is not explicitely set).

Could it be that there happened a ZTS regression when updating the ini
scanner? In 5.2.3 it worked correctly.

I think I write now a bug report and paste this mail conversation into it.

16 years ago by Antony Dovgal — view source

unread

Until now, I have no error location. I think I will look into the changes in
configure.in and look for test calls and try to modify them.

Thanks.

Starting configure with sh -v did not work it only prints a few messages at
beginning but then switches to another shell (???). The problem is fixed if
you start configure with "bash configure". But it would be good to fix this.

Yes, I've already CCed Jani, who's responsible for this part.

I looked into it:
The problem seems to be ZTS specific.
What we have:

First, the value looks correct in phpinfo().

Second setting the value to 6039 (which is the default from php.ini)
produces now a lot of more and very strange error messages when running
PHP scripts.

It seems that the webserver puts the value somewhere to a global place
because after that ALL PHP scripts print very strange things (even those
where this value is not explicitely set).

How EXACTLY does the web-server put the value?
To me it looks like you're using some global config file, so no wonder it's put globally.

Could it be that there happened a ZTS regression when updating the ini
scanner? In 5.2.3 it worked correctly.

I don't know what exactly is the problem and how to reproduce it, so it makes little sense to ask me about it.
Do you have a short reproduce case that doesn't require Solaris, Sun Web server and other stuff we don't have?

--
Wbr,
Antony Dovgal

16 years ago by Uwe Schindler — view source

unread

I looked into it:
The problem seems to be ZTS specific.
What we have:

First, the value looks correct in phpinfo().

Second setting the value to 6039 (which is the default from php.ini)
produces now a lot of more and very strange error messages when
running
PHP scripts.

It seems that the webserver puts the value somewhere to a global place
because after that ALL PHP scripts print very strange things (even
those
where this value is not explicitely set).

How EXACTLY does the web-server put the value?
To me it looks like you're using some global config file, so no wonder
it's put globally.

It is not global. The overwritten value is set only for a specific path (you
can be sure that I know how Sun Webserver works, I maintain the NSAPI
module... :-) ).

The changed value then corrupts the ini entry complete. I found out why this
is so, so this is a bug.

The following patch, when reverted fixes it and restores the old behaviour:

http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.8&r2=1.39
.2.2.2.9&pathrev=PHP_5_2

I do not know why, but it seems that this request specific code tries to
overwrite the definition of the ini entry and corrupts it in a ZTS
environment. After that every request this webserver handles (even when not
affected by a overwritten value produces nice error messages.

Could it be that there happened a ZTS regression when updating the ini
scanner? In 5.2.3 it worked correctly.

I don't know what exactly is the problem and how to reproduce it, so it
makes little sense to ask me about it.
Do you have a short reproduce case that doesn't require Solaris, Sun Web
server and other stuff we don't have?

Take Apache on Windows... :)

I doid not want to ask you alone, the mail was to internals@.

16 years ago by Antony Dovgal — view source

unread

How EXACTLY does the web-server put the value?
To me it looks like you're using some global config file, so no wonder
it's put globally.

It is not global. The overwritten value is set only for a specific path (you
can be sure that I know how Sun Webserver works, I maintain the NSAPI
module... :-) ).

The changed value then corrupts the ini entry complete. I found out why this
is so, so this is a bug.

The following patch, when reverted fixes it and restores the old behaviour:

http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.8&r2=1.39
.2.2.2.9&pathrev=PHP_5_2

It's done to prevent overwriting settings set in httpd.conf (aka php_admin_value's).

I do not know why, but it seems that this request specific code tries to
overwrite the definition of the ini entry and corrupts it in a ZTS
environment. After that every request this webserver handles (even when not
affected by a overwritten value produces nice error messages.

I don't know what exactly is the problem and how to reproduce it, so it
makes little sense to ask me about it.
Do you have a short reproduce case that doesn't require Solaris, Sun Web
server and other stuff we don't have?

Take Apache on Windows... :)

Do you mean you were able to reproduce it with Apache on Windows?

--
Wbr,
Antony Dovgal

16 years ago by Uwe Schindler — view source

unread

How EXACTLY does the web-server put the value?
To me it looks like you're using some global config file, so no wonder
it's put globally.

It is not global. The overwritten value is set only for a specific path
(you
can be sure that I know how Sun Webserver works, I maintain the NSAPI
module... :-) ).

The changed value then corrupts the ini entry complete. I found out why
this
is so, so this is a bug.

The following patch, when reverted fixes it and restores the old
behaviour:

http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.8&r2=1.
39

.2.2.2.9&pathrev=PHP_5_2

It's done to prevent overwriting settings set in httpd.conf (aka
php_admin_value's).

I know how this is meant. But without the added patch, it does not corrupt
error_reporting. The problem is that your patch is not compatible to a
webserver that runs more than one request per process (a multithreaded one),
because it modifies the ini setting in a way that affects later running
threads.

I try to find a way to reproduce it in other webservers.

This is the code that NSAPI uses to modify the INI entries:
entry->param->name is the nullterminated ini key name, entry->param->value
is the nullteminated value. This code runs on every request (like in apache
a php_(admin)_value) that needs to set some specific ini-values. The server
runs only one process that handles all requests in its lifetime because it
is multithreaded:

. It is always runned with admin "privileges" because SJSWS does not have
htaccess files. The big advantage to have the possibility to set ini values
is, that it is not server-wide you can change the call to PHP SAPI e.g. per
virtual server or URI path (see documentation of NSAPI).

Uwe

16 years ago by Antony Dovgal — view source

unread

I know how this is meant. But without the added patch, it does not corrupt
error_reporting. The problem is that your patch is not compatible to a
webserver that runs more than one request per process (a multithreaded one),
because it modifies the ini setting in a way that affects later running
threads.

Ok, I see.
Please fill a bug report and assign it to me, I'll deal with it.

--
Wbr,
Antony Dovgal

16 years ago by Uwe Schindler — view source

unread

I reopened the original bug reported that lead to your change.

At the moment I am trying to fix that. I moved your code a few lines down in
zend_alter_ini_entry but until now with no success.

I suppose there is something special with error reporting that corrupts it.
It seems that it does not like it to be changed to ZEND_INI_SYSTEM because
the @operator tries to change the value (e.g. in zend_vm_execute.h), which
fails silently:

static int ZEND_BEGIN_SILENCE_SPEC_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
zend_op *opline = EX(opline);

Z_LVAL(EX_T(opline->result.u.var).tmp_var) = EG(error_reporting);
Z_TYPE(EX_T(opline->result.u.var).tmp_var) = IS_LONG;  /* shouldn't

be necessary */
if (EX(old_error_reporting) == NULL) {
EX(old_error_reporting) =
&EX_T(opline->result.u.var).tmp_var;
}

if (EG(error_reporting)) {
	zend_alter_ini_entry("error_reporting",

sizeof("error_reporting"), "0", 1, ZEND_INI_USER, ZEND_INI_STAGE_RUNTIME);
}
ZEND_VM_NEXT_OPCODE();
}

Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany

-----Original Message-----
From: Antony Dovgal [mailto:antony@zend.com]
Sent: Friday, August 03, 2007 3:15 PM
To: Uwe Schindler
Cc: 'Ilia Alshanetsky'; 'PHP Internals'
Subject: Re: [PHP-DEV] 5.2.4RC1 Released

I know how this is meant. But without the added patch, it does not
corrupt
error_reporting. The problem is that your patch is not compatible to a
webserver that runs more than one request per process (a multithreaded
one),
because it modifies the ini setting in a way that affects later running
threads.

Ok, I see.
Please fill a bug report and assign it to me, I'll deal with it.

--
Wbr,
Antony Dovgal

16 years ago by Antony Dovgal — view source

unread

I reopened the original bug reported that lead to your change.

At the moment I am trying to fix that. I moved your code a few lines down in
zend_alter_ini_entry but until now with no success.

No, that won't work I guess.
At the moment I can only think of a special hashtable storing all the values that
were set during the INI_SYSTEM stage, so that users could not override them in their scripts.

I suppose there is something special with error reporting that corrupts it.

That special thing is in your config file =)

It seems that it does not like it to be changed to ZEND_INI_SYSTEM because
the @operator tries to change the value (e.g. in zend_vm_execute.h), which
fails silently:

This's a special case and it's really great you noticed it in RC..
We need a workaround for this special case, as if we make all INI directives set
using php_admin_value non-changeable, we break the @ thing.
So we either need to change the @ not to use zend_alter_ini_entry, or make an
exception in that function, which I believe would be a hack.

--
Wbr,
Antony Dovgal

16 years ago by Uwe Schindler — view source

unread

This's a special case and it's really great you noticed it in RC..
We need a workaround for this special case, as if we make all INI
directives set
using php_admin_value non-changeable, we break the @ thing.
So we either need to change the @ not to use zend_alter_ini_entry, or make
an
exception in that function, which I believe would be a hack.

Thats correct. An idea would be to make the @ operator only change
EG(error_reporting) without changing the whole ini-entry by alter_ini_entry
(which is a big slowdown...).

16 years ago by Ilia Alshanetsky — view source

unread

This's a special case and it's really great you noticed it in RC..
We need a workaround for this special case, as if we make all INI
directives set
using php_admin_value non-changeable, we break the @ thing.
So we either need to change the @ not to use zend_alter_ini_entry,
or make
an
exception in that function, which I believe would be a hack.

Thats correct. An idea would be to make the @ operator only change
EG(error_reporting) without changing the whole ini-entry by
alter_ini_entry
(which is a big slowdown...).

The problem with that fix that a crash would potentially leave the
error blocking on, and INI clean up will not reset it.

Ilia Alshanetsky

16 years ago by Uwe Schindler — view source

unread

This's a special case and it's really great you noticed it in RC..
We need a workaround for this special case, as if we make all INI
directives set
using php_admin_value non-changeable, we break the @ thing.
So we either need to change the @ not to use zend_alter_ini_entry,
or make
an
exception in that function, which I believe would be a hack.

Thats correct. An idea would be to make the @ operator only change
EG(error_reporting) without changing the whole ini-entry by
alter_ini_entry
(which is a big slowdown...).

The problem with that fix that a crash would potentially leave the
error blocking on, and INI clean up will not reset it.

The problem with the original fix of antony was the same: The first time any
thread started to modify any INI entry it was marked as "admin"-only for the
whole PHP server until a restart and it stayed in that state because the
flag was changed before the hash table was replicated. This is a second
bug. So at least the lines of antony must moved a few lines down in code...

Uwe

16 years ago by Uwe Schindler — view source

unread

This's a special case and it's really great you noticed it in RC..
We need a workaround for this special case, as if we make all INI
directives set
using php_admin_value non-changeable, we break the @ thing.
So we either need to change the @ not to use zend_alter_ini_entry,
or make
an
exception in that function, which I believe would be a hack.

Thats correct. An idea would be to make the @ operator only change
EG(error_reporting) without changing the whole ini-entry by
alter_ini_entry
(which is a big slowdown...).

The problem with that fix that a crash would potentially leave the
error blocking on, and INI clean up will not reset it.

The problem with the original fix of antony was the same: The first time
any
thread started to modify any INI entry it was marked as "admin"-only for
the
whole PHP server until a restart and it stayed in that state because the
flag was changed before the hash table was replicated. This is a second
bug. So at least the lines of antony must moved a few lines down in
code...

I attached a patch. This patch must be applied in all cases. A second thing
is to remove breakage of the @ operator.

Uwe

16 years ago by Uwe Schindler — view source

unread

This's a special case and it's really great you noticed it in RC..
We need a workaround for this special case, as if we make all INI
directives set
using php_admin_value non-changeable, we break the @ thing.
So we either need to change the @ not to use zend_alter_ini_entry,
or make
an
exception in that function, which I believe would be a hack.

Thats correct. An idea would be to make the @ operator only change
EG(error_reporting) without changing the whole ini-entry by
alter_ini_entry
(which is a big slowdown...).

The problem with that fix that a crash would potentially leave the
error blocking on, and INI clean up will not reset it.

The problem with the original fix of antony was the same: The first time
any
thread started to modify any INI entry it was marked as "admin"-only for
the
whole PHP server until a restart and it stayed in that state because the
flag was changed before the hash table was replicated. This is a
second
bug. So at least the lines of antony must moved a few lines down in
code...

I attached a patch. This patch must be applied in all cases. A second
thing
is to remove breakage of the @ operator.

Oh I forgot, this does not help, too. Because the ADMIN-only status given by
antonys patch (change of ini_entry->modifiable) is not rolled back after
request shutdown.

For the Apache-Not-Multithreaded people a description of the problem:

An Apache server administrator has 2 virtual servers:

One with the original php.ini configuration and no php_admin_values.
One with a modified value that is set by php_admin_value. The setting is
overwritten on the first request of the second virtual server. This is ok,
because the value is restored after the request finishes. But the problem is
that Antonys patch marked the flag as "admin" only, which is not reverted at
end of request. The first virtual server without the php_admin_value will
also have the ini-setting marked as "ADMIN" only until end of time :(

Uwe

16 years ago by Jani Taskinen — view source

unread

Generating files
/configure: test: argument expected
pangaeaw@pansrv1:~/install/php-5.2.4RC1$

It might be the configure options macro I added..but I can't see why any
'test' calls in it wouldn't work?

Anyways, to get more output from configure you can change the hashbang
line in it to:

#! /bin/sh -x

And then run configure something like this:

./configure 2> err

Then 'err' will contain the debug output..

--Jani

16 years ago by Uwe Schindler — view source

unread

Hello again,

got it configured on Solaris with "bash configure ...".

The following two things are problematic:

@-operator before function names does not suppress warning messages
anymore? Whats wrong?
I got for example messages like "cannot open file..." even when it was
opened with @fopen(...).
make test is broken:
pangaeaw@pansrv1:~/install/php-5.2.4RC1$ gmake test

Build complete.
Don't forget to run 'make test'.

/bin/sh: syntax error at line 1: `;' unexpected
gmake: [test] Error 2 (ignored)

Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany

-----Original Message-----
From: Ilia Alshanetsky [mailto:ilia@prohost.org]
Sent: Friday, August 03, 2007 1:37 AM
To: PHP Internals
Subject: [PHP-DEV] 5.2.4RC1 Released

As promised two weeks ago, the 5.2.4RC1 was released today and the
sources for the release can be found here:

http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum:
43e28d2aa55b6c8bcd67da16e24b225a)

Windows binaries should become available in short order as well.

This release have been long in the making so the changelog is a bit
intimidating, so we definitely need a lot of testing for this
release. I would like to ask everyone to give this RC a shot and see
how it behaves with their code and hopefully not find any
regressions. If you do find any, please let us know. Now that RC1 is
out, I would like to ask all developers to refrain from making any
feature additions to 5.2.4 at this time and only apply bug fixes. I
am hoping to have RC2 released within 2 weeks from now and if it
proves to be stable move onto the final release a week from then. So,
if all goes well we should have 5.2.4 out within a month or less.

One exception to the rule I'd like to make known is Stas' ini system
patch, which I feel we should include, but that's still being
currently discussed. Aside from those, no feature additions, please.

Ilia Alshanetsky

16 years ago by Lester Caine — view source

unread

Ilia Alshanetsky wrote:

As promised two weeks ago, the 5.2.4RC1 was released today

Ilia please can you make sure that the bug
http://bugs.php.net/bug.php?id=41429 is at least rolled back to the 5.2.1
state for 5.2.4 - as it currently stands it is causing problems.

--
Lester Caine - G8HFL

Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php

16 years ago by Antony Dovgal — view source

unread

Ilia Alshanetsky wrote:

As promised two weeks ago, the 5.2.4RC1 was released today

Ilia please can you make sure that the bug
http://bugs.php.net/bug.php?id=41429 is at least rolled back to the 5.2.1
state for 5.2.4 - as it currently stands it is causing problems.

Lester, why don't you just try and fix it?

Blindly reverting something is no fix, those changes were done for a good reason, even
though Marcus didn't test them very good (but that's what RCs are for, isn't it?).

I can even tell you which lines were changed since 5_1:
http://cvs.php.net/viewvc.cgi/php-src/ext/interbase/ibase_blobs.c?r1=1.13&r2=1.9.2.2

--
Wbr,
Antony Dovgal

16 years ago by Lester Caine — view source

unread

Antony Dovgal wrote:

Ilia Alshanetsky wrote:

As promised two weeks ago, the 5.2.4RC1 was released today

Ilia please can you make sure that the bug
http://bugs.php.net/bug.php?id=41429 is at least rolled back to the
5.2.1 state for 5.2.4 - as it currently stands it is causing problems.

Lester, why don't you just try and fix it?

Not yet been able to BUILD my own copy of PHP on windows and I don't have time
as I am still TESTING 5.2.3!!!

Blindly reverting something is no fix, those changes were done for a
good reason, even though Marcus didn't test them very good (but that's
what RCs are for, isn't it?).

Obviously they were not tested at all?
There may be some subtle reason why this has been changed and OUR current fix
is to load a copy of the 5.2.1 version which fixes the bug - so until someone
explains why it was changed then reverting works fine.

I had to give up switching to 5.2 as I did not have the time to fix all the
problems that it was throwing up. 5.1.6 has been running fine in production! I
created some time to work through all the problems and I now have a working
5.2.3 installation - with some hacks to get round this bug, and now I need to
spend time with 5.2.4RC1 WHEN the windows build is up.

I can even tell you which lines were changed since 5_1:
http://cvs.php.net/viewvc.cgi/php-src/ext/interbase/ibase_blobs.c?r1=1.13&r2=1.9.2.2

Then it should be possible for someone who HAS commit rights to actually make
it work? Currently the php_interbase driver is almost unusable in PHP5.2 as
shipped, but the 5.2.1 copy works fine.

--
Lester Caine - G8HFL

16 years ago by Antony Dovgal — view source

unread

Blindly reverting something is no fix, those changes were done for a
good reason, even though Marcus didn't test them very good (but that's
what RCs are for, isn't it?).

Obviously they were not tested at all?

I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions).
So even if somebody did run the tests against an RC, he/she didn't tell a word to us.

There may be some subtle reason why this has been changed and OUR current fix
is to load a copy of the 5.2.1 version which fixes the bug - so until someone
explains why it was changed then reverting works fine.

I had to give up switching to 5.2 as I did not have the time to fix all the
problems that it was throwing up.

What kind of problems?

Then it should be possible for someone who HAS commit rights to actually make
it work?

Yes, if only this somebody has Windows build env, Interbase and will to help us.
Unfortunately we don't have such people in PHP community.
Edin and Pierre are two people doing windows builds, but none of them use Interbase as far as I know.

I must also note that you don't have to have commit rights to cook a patch and send it to the list.

Currently the php_interbase driver is almost unusable in PHP5.2 as
shipped, but the 5.2.1 copy works fine.

Try the very next snapshot, I applied a patch after a discussion with Marcus.

--
Wbr,
Antony Dovgal

16 years ago by Pierre — view source

unread

Blindly reverting something is no fix, those changes were done for a
good reason, even though Marcus didn't test them very good (but that's
what RCs are for, isn't it?).

Obviously they were not tested at all?

Each PHP releases have RCs. Maybe this extension needs more tests
(written in php) so one (for example you :) can quickly run the tests
using a given RC or release.

Currently the php_interbase driver is almost unusable in PHP5.2 as
shipped, but the 5.2.1 copy works fine.

Try the very next snapshot, I applied a patch after a discussion with Marcus.

Meaning not the "Aug 03, 2007 08:30 UTC" snap but the next one :)

--Pierre

16 years ago by Lester Caine — view source

unread

Antony Dovgal wrote:

Blindly reverting something is no fix, those changes were done for a
good reason, even though Marcus didn't test them very good (but
that's what RCs are for, isn't it?).

Obviously they were not tested at all?

I don't know of any people using Interbase except for you and Ard (who
maintains all interbase extensions).
So even if somebody did run the tests against an RC, he/she didn't tell
a word to us.

The main reason this problem has now become a problem is a number of long time
PHP4 users who have been convinced to move to PHP5 - only to fall at the first
hurdle :(

Currently the php_interbase driver is almost unusable in PHP5.2 as
shipped, but the 5.2.1 copy works fine.

Try the very next snapshot, I applied a patch after a discussion with
Marcus.

Once it pops out as a windows build ;)

--
Lester Caine - G8HFL

16 years ago by Antony Dovgal — view source

unread

Obviously they were not tested at all?

I don't know of any people using Interbase except for you and Ard (who
maintains all interbase extensions).
So even if somebody did run the tests against an RC, he/she didn't tell
a word to us.

The main reason this problem has now become a problem is a number of long time
PHP4 users who have been convinced to move to PHP5 - only to fall at the first
hurdle :(

It's good to hear that PHP4 users finally decided to move to PHP5.

Currently the php_interbase driver is almost unusable in PHP5.2 as
shipped, but the 5.2.1 copy works fine.

Try the very next snapshot, I applied a patch after a discussion with
Marcus.

Once it pops out as a windows build ;)

It should be already there, please check it out.

--
Wbr,
Antony Dovgal

16 years ago by Lester Caine — view source

unread

Antony Dovgal wrote:

Obviously they were not tested at all?

I don't know of any people using Interbase except for you and Ard
(who maintains all interbase extensions).
So even if somebody did run the tests against an RC, he/she didn't
tell a word to us.

The main reason this problem has now become a problem is a number of
long time PHP4 users who have been convinced to move to PHP5 - only to
fall at the first hurdle :(

It's good to hear that PHP4 users finally decided to move to PHP5.

I still have a couple of problems to investigate, but I'm sure that they are
just the differences in the much improved version of php_interbase that is
shipped with PHP5. A lot of the good stuff was never ported back :(

Currently the php_interbase driver is almost unusable in PHP5.2 as
shipped, but the 5.2.1 copy works fine.

Try the very next snapshot, I applied a patch after a discussion with
Marcus.

Once it pops out as a windows build ;)

It should be already there, please check it out.

OK - Thanks Antony - that is looking fine. I'm happier now to move it to a
production machine and see what the results are with a bit of load.

--
Lester Caine - G8HFL

16 years ago by Antony Dovgal — view source

unread

It should be already there, please check it out.

OK - Thanks Antony - that is looking fine. I'm happier now to move it to a
production machine and see what the results are with a bit of load.

Does this mean you've tested it and it works fine now?

--
Wbr,
Antony Dovgal

16 years ago by Lester Caine — view source

unread

Antony Dovgal wrote:

It should be already there, please check it out.

OK - Thanks Antony - that is looking fine. I'm happier now to move it
to a production machine and see what the results are with a bit of load.

Does this mean you've tested it and it works fine now?

Yep - all the combinations that are failing on 5.2.3 are working fine on the
snapshot, and the debugger is showing '0x0000000f00000123' instead of the
incorrect '0x %i'

And my site stuff is all working as I expect.

--
Lester Caine - G8HFL

16 years ago by Antony Dovgal — view source

unread

Antony Dovgal wrote:

It should be already there, please check it out.

OK - Thanks Antony - that is looking fine. I'm happier now to move it
to a production machine and see what the results are with a bit of load.

Does this mean you've tested it and it works fine now?

Yep - all the combinations that are failing on 5.2.3 are working fine on the
snapshot, and the debugger is showing '0x0000000f00000123' instead of the
incorrect '0x %i'

And my site stuff is all working as I expect.

Great, thanks for your feedback!

--
Wbr,
Antony Dovgal

16 years ago by Jordan Wambaugh — view source

unread

Please forgive my ignorance, as I am relatively new to PHP extension building.
Is there a document published anywhere that describes how to make extensions unicode safe for php6?
Thanks!

Jordan CM Wambaugh

16 years ago by Sebastian Bergmann — view source

unread

Jordan Wambaugh schrieb:

Is there a document published anywhere that describes how to make
extensions unicode safe for php6?

http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE?view=markup
http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE-UPGRADES?view=markup

--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

16 years ago by Jordan Wambaugh — view source

unread

Jordan Wambaugh schrieb:

Is there a document published anywhere that describes how to make
extensions unicode safe for php6?

http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE?view=markup
http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE-UPGRADES?view=markup

--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Thanks sebastian.

--
Jordan CM Wambaugh

16 years ago by Matteo Beccati — view source

unread

Hi,

Ilia Alshanetsky wrote:

As promised two weeks ago, the 5.2.4RC1 was released today and the
sources for the release can be found here:

Not sure if it'a bug... a broken script in PHP 5.2.4RC1 halts execution
because of memory limit:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 24 bytes) in /foo/bar.php on line 88

while 5.2.3 was stopping with:

Fatal error: Nesting level too deep - recursive dependency? in
/foo/bar.php on line 41

Best regards

Matteo Beccati

Openads - http://www.openads.org

16 years ago by Uwe Schindler — view source

unread

Hallo Jani,

thanks,
the configure error is gone! "gmake test" still fails with "/bin/sh: syntax
error at line 1: `;' unexpected"

Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany

From: Jani Taskinen [mailto:jani.taskinen@sci.fi]
Sent: Friday, August 03, 2007 12:48 PM
To: Uwe Schindler
Subject: RE: [PHP-DEV] 5.2.4RC1 Released

I changed one added 'test' line in acinclude.m4 and committed it..so try
the latest PHP_5_2 checkout.

--Jani

Configuring on Solaris (2.10) no longer works, ist the old problem with
"test" that is more strict on solaris:

..
checking dynamic linker characteristics... solaris2.10 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no

Generating files
/configure: test: argument expected
pangaeaw@pansrv1:~/install/php-5.2.4RC1$

config.log does not show anything special:
..
configure:113510: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fPIC -DPIC conftest.cpp 1>&5
configure:113514: $? = 0
configure:113552: checking if c++ supports -c -o file.o
configure:113572: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -o out/conftest2.o conftest.cpp
1>&5
configure:113576: $? = 0
configure:113623: checking whether the c++ linker (/usr/ccs/bin/ld)
supports
shared libraries
configure:113709: checking dynamic linker characteristics
configure:114283: checking how to hardcode library paths into programs
configure:114321: checking whether stripping libraries is possible

Uwe

Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany

From: Ilia Alshanetsky [mailto:ilia@prohost.org]
Sent: Friday, August 03, 2007 1:37 AM
To: PHP Internals
Subject: [PHP-DEV] 5.2.4RC1 Released

As promised two weeks ago, the 5.2.4RC1 was released today and the
sources for the release can be found here:

http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum:
43e28d2aa55b6c8bcd67da16e24b225a)

Windows binaries should become available in short order as well.

This release have been long in the making so the changelog is a bit
intimidating, so we definitely need a lot of testing for this
release. I would like to ask everyone to give this RC a shot and see
how it behaves with their code and hopefully not find any
regressions. If you do find any, please let us know. Now that RC1 is
out, I would like to ask all developers to refrain from making any
feature additions to 5.2.4 at this time and only apply bug fixes. I
am hoping to have RC2 released within 2 weeks from now and if it
proves to be stable move onto the final release a week from then. So,
if all goes well we should have 5.2.4 out within a month or less.

One exception to the rule I'd like to make known is Stas' ini system
patch, which I feel we should include, but that's still being
currently discussed. Aside from those, no feature additions, please.

Ilia Alshanetsky

16 years ago by Jani Taskinen — view source

unread

One down, one to go.. :)

--Jani

Hallo Jani,

thanks,
the configure error is gone! "gmake test" still fails with "/bin/sh: syntax
error at line 1: `;' unexpected"

Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany

From: Jani Taskinen [mailto:jani.taskinen@sci.fi]
Sent: Friday, August 03, 2007 12:48 PM
To: Uwe Schindler
Subject: RE: [PHP-DEV] 5.2.4RC1 Released

I changed one added 'test' line in acinclude.m4 and committed it..so try
the latest PHP_5_2 checkout.

--Jani

Configuring on Solaris (2.10) no longer works, ist the old problem with
"test" that is more strict on solaris:

..
checking dynamic linker characteristics... solaris2.10 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no

Generating files
/configure: test: argument expected
pangaeaw@pansrv1:~/install/php-5.2.4RC1$

config.log does not show anything special:
..
configure:113510: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fPIC -DPIC conftest.cpp 1>&5
configure:113514: $? = 0
configure:113552: checking if c++ supports -c -o file.o
configure:113572: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -o out/conftest2.o conftest.cpp
1>&5
configure:113576: $? = 0
configure:113623: checking whether the c++ linker (/usr/ccs/bin/ld)
supports
shared libraries
configure:113709: checking dynamic linker characteristics
configure:114283: checking how to hardcode library paths into programs
configure:114321: checking whether stripping libraries is possible

Uwe

Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany

From: Ilia Alshanetsky [mailto:ilia@prohost.org]
Sent: Friday, August 03, 2007 1:37 AM
To: PHP Internals
Subject: [PHP-DEV] 5.2.4RC1 Released

As promised two weeks ago, the 5.2.4RC1 was released today and the
sources for the release can be found here:

http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum:
43e28d2aa55b6c8bcd67da16e24b225a)

Windows binaries should become available in short order as well.

This release have been long in the making so the changelog is a bit
intimidating, so we definitely need a lot of testing for this
release. I would like to ask everyone to give this RC a shot and see
how it behaves with their code and hopefully not find any
regressions. If you do find any, please let us know. Now that RC1 is
out, I would like to ask all developers to refrain from making any
feature additions to 5.2.4 at this time and only apply bug fixes. I
am hoping to have RC2 released within 2 weeks from now and if it
proves to be stable move onto the final release a week from then. So,
if all goes well we should have 5.2.4 out within a month or less.

One exception to the rule I'd like to make known is Stas' ini system
patch, which I feel we should include, but that's still being
currently discussed. Aside from those, no feature additions, please.

Ilia Alshanetsky

16 years ago by Lester Caine — view source

unread

Lorenzo Alberton wrote:

Antony Dovgal wrote:

Blindly reverting something is no fix, those changes were done for a
good reason, even though Marcus didn't test them very good (but
that's what RCs are for, isn't it?).

Obviously they were not tested at all?

I don't know of any people using Interbase except for you and Ard (who
maintains all interbase extensions).

I do (btw, I'm the maintainer of PEAR::MDB2, including the ibase
driver), and I know a lot of people using Firebird/Interbase.
Unfortunately, since PDO_Firebird is completely broken [1]
and Ard isn't active anymore, the only option left is using
the current php_interbase extension.

Ard was amongst the list of people who could not see any need to develop a
second driver since the php_interbase one IS working fine. It would be nice to
build a Firebird version against the modern client, and do away with the need
to build a legacy client to allow it to work. That IS in the pipeline, but as
yet no-one who uses Firebird/PHP in production has seen any need to spend time
on a more limited PDO driver ;) Ard had built a lot of capability into the
driver, and has added all the hooks for an fbird port already for a split,
which is probably now due given the extensive work Firebird has received in
the version 2 builds, and the new service facilities that it would be nice to
support directly. But even the existing php_interbase handles FB2.x without a
problem.

--
Lester Caine - G8HFL

16 years ago by Pierre — view source

unread

Hi Lester,

Ard was amongst the list of people who could not see any need to develop a
second driver since the php_interbase one IS working fine. It would be nice to
build a Firebird version against the modern client, and do away with the need
to build a legacy client to allow it to work. That IS in the pipeline, but as
yet no-one who uses Firebird/PHP in production has seen any need to spend time
on a more limited PDO driver ;) Ard had built a lot of capability into the
driver, and has added all the hooks for an fbird port already for a split,
which is probably now due given the extensive work Firebird has received in
the version 2 builds, and the new service facilities that it would be nice to
support directly. But even the existing php_interbase handles FB2.x without a
problem.

That's nice and I'm sure Ard's work is highly appreciated by the
firebird users. But I completely disagree with this strategy (mysql
follows it too). In the long run you will simply loose more php
"market" in favour of databases with good PDO support.

I'm not saying that PDO is perfect (it is not), but pdo adoptions is
growing and to be supported by PDO becomes more and more a must.

I would to see more databases developers helping the PDO developers to
improve it, to add what they need to write good drivers. It will be
all benefits for the PHP users and for the DB developers (if they want
more customers/users).
</utopia>

--Pierre

16 years ago by Lester Caine — view source

unread

Pierre wrote:

Hi Lester,

Ard was amongst the list of people who could not see any need to develop a
second driver since the php_interbase one IS working fine. It would be nice to
build a Firebird version against the modern client, and do away with the need
to build a legacy client to allow it to work. That IS in the pipeline, but as
yet no-one who uses Firebird/PHP in production has seen any need to spend time
on a more limited PDO driver ;) Ard had built a lot of capability into the
driver, and has added all the hooks for an fbird port already for a split,
which is probably now due given the extensive work Firebird has received in
the version 2 builds, and the new service facilities that it would be nice to
support directly. But even the existing php_interbase handles FB2.x without a
problem.

That's nice and I'm sure Ard's work is highly appreciated by the
firebird users. But I completely disagree with this strategy (mysql
follows it too). In the long run you will simply loose more php
"market" in favour of databases with good PDO support.

I'm not saying that PDO is perfect (it is not), but pdo adoptions is
growing and to be supported by PDO becomes more and more a must.

I would to see more databases developers helping the PDO developers to
improve it, to add what they need to write good drivers. It will be
all benefits for the PHP users and for the DB developers (if they want
more customers/users).
</utopia>

Sorry Pierre I have to disagree there. Most flexible projects are built on
ADOdb, and while you CAN use PDO as an alternative driver, for the best
performance the raw drivers are preferable. I don't see anything to replace
the SQL handling that ADOdb provides although the ADOdbLite does work well if
you do not want a fully featured interface and can do without some of the more
advanced SQL code. Being able to build a project for ANY database is nice to
have but requires you manage the SQL as well as the data, and if you are not
building a generic project then you don't need a generic driver.

I keep being told that the PDO drivers can be extended to include all of the
things already available in the native driver, but the second you do that they
become incompatible, so in addition to the PDO driver you need to also run the
native driver simply to provide the areas NOT covered by PDO. We need a
generic framework that addresses the real problems not one that creates an
artificial lowest common denominator strangle hold :( PDO could evolve into
that, but not with it's current restrictions.

--
Lester Caine - G8HFL

16 years ago by Christopher Jones — view source

unread

Lester Caine wrote:

I keep being told that the PDO drivers can be extended to include all of
the things already available in the native driver, but the second you do
that they become incompatible, so in addition to the PDO driver you need
to also run the native driver simply to provide the areas NOT covered by
PDO. We need a generic framework that addresses the real problems not
one that creates an artificial lowest common denominator strangle hold
:( PDO could evolve into that, but not with it's current restrictions.

Hi Lester,

Can you list the current restrictions as you see them?

Chris

--
Christopher Jones, Oracle
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad

16 years ago by Lester Caine — view source

unread

Christopher Jones wrote:

Lester Caine wrote:

I keep being told that the PDO drivers can be extended to include all
of the things already available in the native driver, but the second
you do that they become incompatible, so in addition to the PDO driver
you need to also run the native driver simply to provide the areas NOT
covered by PDO. We need a generic framework that addresses the real
problems not one that creates an artificial lowest common denominator
strangle hold :( PDO could evolve into that, but not with it's current
restrictions.

Can you list the current restrictions as you see them?

Actually the very first one has been addressed and has nothing to do with PDO.
Up until recently is was essential to provide backwards compatibility with
PHP4 and all of the projects I currently work with WOULD still install on
PHP4. Although I never used it in production, the continued support meant
that there was a large base that insisted on retaining it. So ADOdb's
continued underlying support for PHP4 is useful and until there are a higher
percentage of PHP5 users than PHP4 - PDO takes second place as it is not
available on a large number of hosts?

The next problem builds on the above one. From the PDO manual "PDO does not
provide a database abstraction; it doesn't rewrite SQL or emulate missing
features. You should use a full-blown abstraction layer if you need that
facility." ADOdb will run PDO drivers quite happily, but on current
information the performance of the PDO drivers is slower than using the same
native driver. So given a choice the native one is preferable and currently
essential for PHP4 support.

NEITHER of the above are restricted to Firebird and apply equally to all
databases, but they are the main reason to date that no one has had the
inclination to fix the pdo_firebird driver as it's deployment potential is
currently limited.

The internals of PDO restrict things to using SQL access to the database.
While it will probably be said that the database should ONLY provide SQL
access to everything, Firebird has a services interface which is used for such
things as backup, user management, and the event handler. How should all those
be handled if they are moved to the PDO driver?

PDO provides a basic transaction control that hides the transaction modes. It
can't handle retaining the context of the transaction following a commit or
roll back, or selection a more appropriate transaction mode? CONCURRENCY for
reports at a fixed time point over COMMITTED to handle changes made in other
transactions. How does one switch between a 'wait' and 'nowait' transaction?

The one that prompted this discussion. How do you return a simple handle to a
BLOB object so that you DON'T have to download the whole blob. It can be
useful to hold the blob id so that you only access a sub set of the data from
the blob object. This seems to be missing in PDO?

HAVING to maintain PHP4 support has meant that I have not gone into PDO with a
fine tooth comb, and most of my understanding of the problems of PDO is based
on what has been said elsewhere, but at present I can't see how some of these
fundamental facilities provided by the php_interbase driver would be mirrored
in PDO. I stand to be corrected, and perhaps when PHP4 has died THEN the
supposed advantage of PDO may be a more attractive development path? But at
present there is simply no incentive to move over :(

--
Lester Caine - G8HFL

16 years ago by Lester Caine — view source

unread

Lester Caine wrote:

Christopher Jones wrote:

Lester Caine wrote:

I keep being told that the PDO drivers can be extended to include all
of the things already available in the native driver, but the second
you do that they become incompatible, so in addition to the PDO
driver you need to also run the native driver simply to provide the
areas NOT covered by PDO. We need a generic framework that addresses
the real problems not one that creates an artificial lowest common
denominator strangle hold :( PDO could evolve into that, but not with
it's current restrictions.

Can you list the current restrictions as you see them?

Actually the very first one has been addressed and has nothing to do
with PDO. Up until recently is was essential to provide backwards
compatibility with PHP4 and all of the projects I currently work with
WOULD still install on PHP4. Although I never used it in production,
the continued support meant that there was a large base that insisted on
retaining it. So ADOdb's continued underlying support for PHP4 is useful
and until there are a higher percentage of PHP5 users than PHP4 - PDO
takes second place as it is not available on a large number of hosts?

The next problem builds on the above one. From the PDO manual "PDO does
not provide a database abstraction; it doesn't rewrite SQL or emulate
missing features. You should use a full-blown abstraction layer if you
need that facility." ADOdb will run PDO drivers quite happily, but on
current information the performance of the PDO drivers is slower than
using the same native driver. So given a choice the native one is
preferable and currently essential for PHP4 support.

NEITHER of the above are restricted to Firebird and apply equally to all
databases, but they are the main reason to date that no one has had the
inclination to fix the pdo_firebird driver as it's deployment potential
is currently limited.

The internals of PDO restrict things to using SQL access to the
database. While it will probably be said that the database should ONLY
provide SQL access to everything, Firebird has a services interface
which is used for such things as backup, user management, and the event
handler. How should all those be handled if they are moved to the PDO
driver?

PDO provides a basic transaction control that hides the transaction
modes. It can't handle retaining the context of the transaction
following a commit or roll back, or selection a more appropriate
transaction mode? CONCURRENCY for reports at a fixed time point over
COMMITTED to handle changes made in other transactions. How does one
switch between a 'wait' and 'nowait' transaction?

The one that prompted this discussion. How do you return a simple handle
to a BLOB object so that you DON'T have to download the whole blob. It
can be useful to hold the blob id so that you only access a sub set of
the data from the blob object. This seems to be missing in PDO?

HAVING to maintain PHP4 support has meant that I have not gone into PDO
with a fine tooth comb, and most of my understanding of the problems of
PDO is based on what has been said elsewhere, but at present I can't see
how some of these fundamental facilities provided by the php_interbase
driver would be mirrored in PDO. I stand to be corrected, and perhaps
when PHP4 has died THEN the supposed advantage of PDO may be a more
attractive development path? But at present there is simply no incentive
to move over :(

Things went quiet :(

Is there anything in my above list this is NOT correct? I do stand to be
corrected about PDO, but at present I can't see how to get around the
limitations even IF the pdo_firebird driver was functional. And I see some of
these restrictions applying to other database engines as well?

--
Lester Caine - G8HFL

16 years ago by Larry Garfield — view source

unread

Lester Caine wrote:

Christopher Jones wrote:

Lester Caine wrote:

I keep being told that the PDO drivers can be extended to include all
of the things already available in the native driver, but the second
you do that they become incompatible, so in addition to the PDO
driver you need to also run the native driver simply to provide the
areas NOT covered by PDO. We need a generic framework that addresses
the real problems not one that creates an artificial lowest common
denominator strangle hold :( PDO could evolve into that, but not with
it's current restrictions.

Can you list the current restrictions as you see them?

Actually the very first one has been addressed and has nothing to do
with PDO. Up until recently is was essential to provide backwards
compatibility with PHP4 and all of the projects I currently work with
WOULD still install on PHP4. Although I never used it in production,
the continued support meant that there was a large base that insisted on
retaining it. So ADOdb's continued underlying support for PHP4 is useful
and until there are a higher percentage of PHP5 users than PHP4 - PDO
takes second place as it is not available on a large number of hosts?

As you noted, this one is no longer an issue[1][2].

[1] http://gophp5.org/
[2] http://www.php.net/index.php#2007-07-13-1

The next problem builds on the above one. From the PDO manual "PDO does
not provide a database abstraction; it doesn't rewrite SQL or emulate
missing features. You should use a full-blown abstraction layer if you
need that facility." ADOdb will run PDO drivers quite happily, but on
current information the performance of the PDO drivers is slower than
using the same native driver. So given a choice the native one is
preferable and currently essential for PHP4 support.

I've seen some of the numbers posted, at least as far as MySQL. As Ilia has
noted before, MySQL's native prepared statement support sucks all on its own.
It's faster to use PDO's internal implementation.

That said, you need to make a direct comparison. PDO, especially with
prepared statements, does a lot more processing than a direct implementation.
That takes a lot more cycles than just passing mysql_query() a string.
However, just passing mysql_query() a string is not secure. You need to
implement your own escaping mechanism on top of it (because trusting yourself
to always call mysql_real_escape_string() in every instance is a recipe for
disaster). That takes even more cycles, because it's happening in PHP rather
than in C.

As a case in point, I recently tried to implement a PDO layer for Drupal as an
alternative to the mysql_* implementation. Drupal currently implements its
own prepared statements in user-space, using a printf()-like syntax and
preg_replace_callback(). When I replaced that with PDO's own prepared
statements, I found performance was about a wash[3]. On the other hand we do
get type-safe prepared statements and simpler code, so we're planning to move
to PDO in Drupal 7 at this point.

[3] http://drupal.org/node/134580

NEITHER of the above are restricted to Firebird and apply equally to all
databases, but they are the main reason to date that no one has had the
inclination to fix the pdo_firebird driver as it's deployment potential
is currently limited.

My knowledge and experience with Firebird is nil, so I cannot say anything
useful for that.

The internals of PDO restrict things to using SQL access to the
database. While it will probably be said that the database should ONLY
provide SQL access to everything, Firebird has a services interface
which is used for such things as backup, user management, and the event
handler. How should all those be handled if they are moved to the PDO
driver?

Are you talking about Firebird-specific features, or all non-SQL-standard
queries? As far as I know PDO allows arbitrary strings as queries so
SQL-esque database-specific stuff should still work. Wez, is that not the
case?

PDO provides a basic transaction control that hides the transaction
modes. It can't handle retaining the context of the transaction
following a commit or roll back, or selection a more appropriate
transaction mode? CONCURRENCY for reports at a fixed time point over
COMMITTED to handle changes made in other transactions. How does one
switch between a 'wait' and 'nowait' transaction?

The one that prompted this discussion. How do you return a simple handle
to a BLOB object so that you DON'T have to download the whole blob. It
can be useful to hold the blob id so that you only access a sub set of
the data from the blob object. This seems to be missing in PDO?

HAVING to maintain PHP4 support has meant that I have not gone into PDO
with a fine tooth comb, and most of my understanding of the problems of
PDO is based on what has been said elsewhere, but at present I can't see
how some of these fundamental facilities provided by the php_interbase
driver would be mirrored in PDO. I stand to be corrected, and perhaps
when PHP4 has died THEN the supposed advantage of PDO may be a more
attractive development path? But at present there is simply no incentive
to move over :(

Things went quiet :(

Is there anything in my above list this is NOT correct? I do stand to be
corrected about PDO, but at present I can't see how to get around the
limitations even IF the pdo_firebird driver was functional. And I see some
of these restrictions applying to other database engines as well?

I make no claim of being a PDO expert either, and my database experience is
98% MySQL, but the above is my experience and reading so far with it. PDO's
main selling points are 1) A fully OO API and 2) A common API for all
databases. By nature, it does result in "lowest common denominator" issues
as well, including potentially performance. If you're aiming for
cross-database compatibility, I'd recommend it over rolling your own. If you
can guarantee that you'll only need <insert some database here>, then the
specific driver may be a better option in some cases. YMMV and so forth.

--
Larry Garfield AIM: LOLG42
larry@garfieldtech.com ICQ: 6817012

"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson

16 years ago by Lukas Kahwe Smith — view source

unread

Larry Garfield wrote:

Lester Caine wrote:

Christopher Jones wrote:

Lester Caine wrote:

I keep being told that the PDO drivers can be extended to include all
of the things already available in the native driver, but the second
you do that they become incompatible, so in addition to the PDO
driver you need to also run the native driver simply to provide the
areas NOT covered by PDO. We need a generic framework that addresses
the real problems not one that creates an artificial lowest common
denominator strangle hold :( PDO could evolve into that, but not with
it's current restrictions.
Can you list the current restrictions as you see them?
Actually the very first one has been addressed and has nothing to do
with PDO. Up until recently is was essential to provide backwards
compatibility with PHP4 and all of the projects I currently work with
WOULD still install on PHP4. Although I never used it in production,
the continued support meant that there was a large base that insisted on
retaining it. So ADOdb's continued underlying support for PHP4 is useful
and until there are a higher percentage of PHP5 users than PHP4 - PDO
takes second place as it is not available on a large number of hosts?

As you noted, this one is no longer an issue[1][2].

[1] http://gophp5.org/
[2] http://www.php.net/index.php#2007-07-13-1

The next problem builds on the above one. From the PDO manual "PDO does
not provide a database abstraction; it doesn't rewrite SQL or emulate
missing features. You should use a full-blown abstraction layer if you
need that facility." ADOdb will run PDO drivers quite happily, but on
current information the performance of the PDO drivers is slower than
using the same native driver. So given a choice the native one is
preferable and currently essential for PHP4 support.

I've seen some of the numbers posted, at least as far as MySQL. As Ilia has
noted before, MySQL's native prepared statement support sucks all on its own.
It's faster to use PDO's internal implementation.

That said, you need to make a direct comparison. PDO, especially with
prepared statements, does a lot more processing than a direct implementation.
That takes a lot more cycles than just passing mysql_query() a string.
However, just passing mysql_query() a string is not secure. You need to
implement your own escaping mechanism on top of it (because trusting yourself
to always call mysql_real_escape_string() in every instance is a recipe for
disaster). That takes even more cycles, because it's happening in PHP rather
than in C.

As a case in point, I recently tried to implement a PDO layer for Drupal as an
alternative to the mysql_* implementation. Drupal currently implements its
own prepared statements in user-space, using a printf()-like syntax and
preg_replace_callback(). When I replaced that with PDO's own prepared
statements, I found performance was about a wash[3]. On the other hand we do
get type-safe prepared statements and simpler code, so we're planning to move
to PDO in Drupal 7 at this point.

[3] http://drupal.org/node/134580

NEITHER of the above are restricted to Firebird and apply equally to all
databases, but they are the main reason to date that no one has had the
inclination to fix the pdo_firebird driver as it's deployment potential
is currently limited.

My knowledge and experience with Firebird is nil, so I cannot say anything
useful for that.

The internals of PDO restrict things to using SQL access to the
database. While it will probably be said that the database should ONLY
provide SQL access to everything, Firebird has a services interface
which is used for such things as backup, user management, and the event
handler. How should all those be handled if they are moved to the PDO
driver?

Are you talking about Firebird-specific features, or all non-SQL-standard
queries? As far as I know PDO allows arbitrary strings as queries so
SQL-esque database-specific stuff should still work. Wez, is that not the
case?

I make no claim of being a PDO expert either, and my database experience is
98% MySQL, but the above is my experience and reading so far with it. PDO's
main selling points are 1) A fully OO API and 2) A common API for all
databases. By nature, it does result in "lowest common denominator" issues
as well, including potentially performance. If you're aiming for
cross-database compatibility, I'd recommend it over rolling your own. If you
can guarantee that you'll only need <insert some database here>, then the
specific driver may be a better option in some cases. YMMV and so forth.

No, the idea is that there is a common set of methods and a common
infrastructure to support those. However every driver is free to
implement driver specific things and prefix those methods with the
driver name. So in theory all the RDBMS specific goodies in all of the
native drivers can also go into PDO.

regards
Lukas

16 years ago by Dan Scott — view source

unread

Larry Garfield wrote:

Lester Caine wrote:

Christopher Jones wrote:

Lester Caine wrote:

I keep being told that the PDO drivers can be extended to include all
of the things already available in the native driver, but the second
you do that they become incompatible, so in addition to the PDO
driver you need to also run the native driver simply to provide the
areas NOT covered by PDO. We need a generic framework that addresses
the real problems not one that creates an artificial lowest common
denominator strangle hold :( PDO could evolve into that, but not with
it's current restrictions.
Can you list the current restrictions as you see them?
Actually the very first one has been addressed and has nothing to do
with PDO. Up until recently is was essential to provide backwards
compatibility with PHP4 and all of the projects I currently work with
WOULD still install on PHP4. Although I never used it in production,
the continued support meant that there was a large base that insisted on
retaining it. So ADOdb's continued underlying support for PHP4 is useful
and until there are a higher percentage of PHP5 users than PHP4 - PDO
takes second place as it is not available on a large number of hosts?

As you noted, this one is no longer an issue[1][2].

[1] http://gophp5.org/
[2] http://www.php.net/index.php#2007-07-13-1

The next problem builds on the above one. From the PDO manual "PDO does
not provide a database abstraction; it doesn't rewrite SQL or emulate
missing features. You should use a full-blown abstraction layer if you
need that facility." ADOdb will run PDO drivers quite happily, but on
current information the performance of the PDO drivers is slower than
using the same native driver. So given a choice the native one is
preferable and currently essential for PHP4 support.

I've seen some of the numbers posted, at least as far as MySQL. As Ilia has
noted before, MySQL's native prepared statement support sucks all on its own.
It's faster to use PDO's internal implementation.

That said, you need to make a direct comparison. PDO, especially with
prepared statements, does a lot more processing than a direct implementation.
That takes a lot more cycles than just passing mysql_query() a string.
However, just passing mysql_query() a string is not secure. You need to
implement your own escaping mechanism on top of it (because trusting yourself
to always call mysql_real_escape_string() in every instance is a recipe for
disaster). That takes even more cycles, because it's happening in PHP rather
than in C.

As a case in point, I recently tried to implement a PDO layer for Drupal as an
alternative to the mysql_* implementation. Drupal currently implements its
own prepared statements in user-space, using a printf()-like syntax and
preg_replace_callback(). When I replaced that with PDO's own prepared
statements, I found performance was about a wash[3]. On the other hand we do
get type-safe prepared statements and simpler code, so we're planning to move
to PDO in Drupal 7 at this point.

[3] http://drupal.org/node/134580

NEITHER of the above are restricted to Firebird and apply equally to all
databases, but they are the main reason to date that no one has had the
inclination to fix the pdo_firebird driver as it's deployment potential
is currently limited.

My knowledge and experience with Firebird is nil, so I cannot say anything
useful for that.

The internals of PDO restrict things to using SQL access to the
database. While it will probably be said that the database should ONLY
provide SQL access to everything, Firebird has a services interface
which is used for such things as backup, user management, and the event
handler. How should all those be handled if they are moved to the PDO
driver?

Are you talking about Firebird-specific features, or all non-SQL-standard
queries? As far as I know PDO allows arbitrary strings as queries so
SQL-esque database-specific stuff should still work. Wez, is that not the
case?

I make no claim of being a PDO expert either, and my database experience is
98% MySQL, but the above is my experience and reading so far with it. PDO's
main selling points are 1) A fully OO API and 2) A common API for all
databases. By nature, it does result in "lowest common denominator" issues
as well, including potentially performance. If you're aiming for
cross-database compatibility, I'd recommend it over rolling your own. If you
can guarantee that you'll only need <insert some database here>, then the
specific driver may be a better option in some cases. YMMV and so forth.

No, the idea is that there is a common set of methods and a common
infrastructure to support those. However every driver is free to
implement driver specific things and prefix those methods with the
driver name. So in theory all the RDBMS specific goodies in all of the
native drivers can also go into PDO.

Right. And Wez posted this (partially in reply to Lester's almost
identical hysterics at that time) on this very list ages ago
(http://news.php.net/php.internals/14937 - Feb 14, 2005, to be exact):

BEGIN QUOTE:
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
END QUOTE

So can we please move on, Lester? If someone who cares about
Firebird wants to beef up the PDO_Firebird driver with all kinds of
Firebird-specific features, the answer is still the same as it was
almost two and a half years ago: the PHP project humbly awaits that
person's patch.

--
Dan Scott
Laurentian University

16 years ago by Lester Caine — view source

unread

Dan Scott wrote:

Right. And Wez posted this (partially in reply to Lester's almost
identical hysterics at that time) on this very list ages ago
(http://news.php.net/php.internals/14937 - Feb 14, 2005, to be exact):

BEGIN QUOTE:
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
END QUOTE

NOTE the (*) - I'm TRYING to reopen the discussion on generic things like
transaction handling. Simply bolting driver specific solutions back into each
different driver in a different way is pointless? We have those drivers
already? The extra's are less of a problem than missing CORE facilities :(

So can we please move on, Lester? If someone who cares about
Firebird wants to beef up the PDO_Firebird driver with all kinds of
Firebird-specific features, the answer is still the same as it was
almost two and a half years ago: the PHP project humbly awaits that
person's patch.

The MAIN problem here is that a number of the things I'm talking about are NOT
Firebird/Interbase specific, and ARE already managed via ADOdb, but they are
currently disabled if you use the PDO driver IN ADOdb. The general consensus
then was that PDO WOULD get round to addressing these areas. In two and a
half years has anything been done yet?

--
Lester Caine - G8HFL

16 years ago by Lukas Kahwe Smith — view source

unread

Lester Caine wrote:

Dan Scott wrote:

Right. And Wez posted this (partially in reply to Lester's almost
identical hysterics at that time) on this very list ages ago
(http://news.php.net/php.internals/14937 - Feb 14, 2005, to be exact):

BEGIN QUOTE:
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
END QUOTE

NOTE the (*) - I'm TRYING to reopen the discussion on generic things
like transaction handling. Simply bolting driver specific solutions back
into each different driver in a different way is pointless? We have
those drivers already? The extra's are less of a problem than missing
CORE facilities :(

Ok, yes this is indeed an issue. PDO does not support nested
transactions. No other RDBMS that I am aware of supports this and for
all I know it does not work in the ibase driver either. Atleast we tried
to use it in MDB2 and never got it to work. Ask Lorenzo for details on this.

However again it does not prevent firebird specific methods for handling
nested transactions, which an abstraction layer author may then choose
to use in a firebird driver.

regards,
Lukas

16 years ago by Lester Caine — view source

unread

Lukas Kahwe Smith wrote:

Lester Caine wrote:

Dan Scott wrote:

Right. And Wez posted this (partially in reply to Lester's almost
identical hysterics at that time) on this very list ages ago
(http://news.php.net/php.internals/14937 - Feb 14, 2005, to be exact):

BEGIN QUOTE:
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
END QUOTE

NOTE the (*) - I'm TRYING to reopen the discussion on generic things
like transaction handling. Simply bolting driver specific solutions
back into each different driver in a different way is pointless? We
have those drivers already? The extra's are less of a problem than
missing CORE facilities :(

Ok, yes this is indeed an issue. PDO does not support nested
transactions. No other RDBMS that I am aware of supports this and for
all I know it does not work in the ibase driver either. Atleast we tried
to use it in MDB2 and never got it to work. Ask Lorenzo for details on
this.

However again it does not prevent firebird specific methods for handling
nested transactions, which an abstraction layer author may then choose
to use in a firebird driver.

You are going beyond where I've got to ;)

I'm just looking to be able to select auto commit on or off, and switch
transaction modes. Something which many 'proper' databases support but which I
do note that other generic drivers only make this available via the connect
string, something which explains why I get different results when changing
from Firebird within ADOdb. I'm simply used to wrapping an update in it's own
transaction, which can be rolled back and then reworked if required.

I will be honest here - never using other databases IN PHP other than via
ADOdb, I had not appreciated that many of the native drivers simply don't
provide access to facilities that I KNOW exist in those databases themselves!
This probably explains why I get such blank responses when trying to get
things sorted.

ibase_trans allows me to set up a package of work on the database, set up the
type of transaction ( something that I KNOW Oracle, DB2 and MsSQL internally
support ). I can build a set of report results using 'concurrency' isolation
level get the results and post them back to the database in a second
transaction, or I can wait on other activity completing before posting the
changes. I think that I had not appreciated that the Oracle, DB2 and MsSQL
drivers have to create a new connection for a new transaction :(

( I'll answer the point on the other post separately - at least I am
beginning to understand how restrictive the PHP interface is to other database
users and that explains why there have been such differences of opinion in the
past ;) )

--
Lester Caine - G8HFL

16 years ago by Lester Caine — view source

unread

Larry Garfield wrote:

As a case in point, I recently tried to implement a PDO layer for Drupal as an
alternative to the mysql_* implementation. Drupal currently implements its
own prepared statements in user-space, using a printf()-like syntax and
preg_replace_callback(). When I replaced that with PDO's own prepared
statements, I found performance was about a wash[3]. On the other hand we do
get type-safe prepared statements and simpler code, so we're planning to move
to PDO in Drupal 7 at this point.

[3] http://drupal.org/node/134580

That nicely summaries some of the aspects of moving to PDO from the user side.
You are thinking that you will have to support PHP4 and non-PDO drivers until
2012 :)

The main thing I see there is 'raw' SQL. Loading the variables directly into
the script, rather than simply binding them as params. I have yet to work out
a way of converting some of my dynamically generated SQL into a format that
will work with PDO - on any database. I've only ever used ADOdb and that
handles ALL of the parameterizing of things transparently.

The other problem of cause is length of table and field names and reserved
words. Adding Oracle and MsSQL to the mix, working with raw upper case table
and field names and 31 character name limit introduces a few extra things to
consider over and above just adding PDO to Drupal ;)

NEITHER of the above are restricted to Firebird and apply equally to all
databases, but they are the main reason to date that no one has had the
inclination to fix the pdo_firebird driver as it's deployment potential
is currently limited.

My knowledge and experience with Firebird is nil, so I cannot say anything
useful for that.

The only point I was making here is the one you have covered - we need to
support PHP4 for some time yet - which ever database you are using :(

The internals of PDO restrict things to using SQL access to the
database. While it will probably be said that the database should ONLY
provide SQL access to everything, Firebird has a services interface
which is used for such things as backup, user management, and the event
handler. How should all those be handled if they are moved to the PDO
driver?

Are you talking about Firebird-specific features, or all non-SQL-standard
queries? As far as I know PDO allows arbitrary strings as queries so
SQL-esque database-specific stuff should still work. Wez, is that not the
case?

There are other interfaces other than just the 'SQL' one for talking to but
then the database industry are working from the other end to come in line with
the standards. Perhaps another one for 2012.

I make no claim of being a PDO expert either, and my database experience is
98% MySQL, but the above is my experience and reading so far with it. PDO's
main selling points are 1) A fully OO API and 2) A common API for all
databases. By nature, it does result in "lowest common denominator" issues
as well, including potentially performance. If you're aiming for
cross-database compatibility, I'd recommend it over rolling your own. If you
can guarantee that you'll only need <insert some database here>, then the
specific driver may be a better option in some cases. YMMV and so forth.

TODAY - I think that is right.
I'm not as negative about PDO as people seem to think! It is just that TODAY
there is a packaged working solution to MY problem, which many other people
are using as well so there is no need to spend time 'rolling your own' version
of PDO that mirrors those facilities?

--
Lester Caine - G8HFL

16 years ago by Lukas Kahwe Smith — view source

unread

Lester Caine wrote:

The main thing I see there is 'raw' SQL. Loading the variables directly
into the script, rather than simply binding them as params. I have yet
to work out a way of converting some of my dynamically generated SQL
into a format that will work with PDO - on any database. I've only ever
used ADOdb and that handles ALL of the parameterizing of things
transparently.

I have no clue what type of dynamically generated SQL you are talking
about. Are you talking about being able to dynamically stick identifiers
into placeholders? This is simply not possible if you are using native
prepared statements. If you emulate them, yes you can, but then you can
might as well use sprintf() with quote() (maybe with a wrapper).

The other problem of cause is length of table and field names and
reserved words. Adding Oracle and MsSQL to the mix, working with raw
upper case table and field names and 31 character name limit introduces
a few extra things to consider over and above just adding PDO to Drupal ;)

PDO handles some of those, but as said tons of times before, its not an
abstraction layer, its an API unifier. There are PDO based layers like
Doctrine, that give you all the convinience of ADODB (and more ..). They
do however require that the underlying PDO driver is solid.

At any rate .. why bother with PDO when there are "native" extensions?
The point of PDO was not only end user focused, it was also the idea to
one day make it less effort to add new features to all the RDBMS
extensions (for example unicode .. that being said I keep hearing that
PDO HEAD is totally out of sync). It also makes it a lot easier to add a
new RDBMS extension.

Now if we stick with maintaining the current non PDO extensions, then
you must realize that we are maintaining a lot of redundant code, which
is based on one of the oldest extensions (ext/mysql). Since we do not
have infinite development resources, it would be for the better of any
of the supported RDBMS if it would get its PDO driver up to the same
level as the old extension. As more and more of our userbase is moving
to PHP5 this hopefully will become more and more interesting.

regards,
Lukas

16 years ago by Lester Caine — view source

unread

Following on ....

Lukas Kahwe Smith wrote:

Lester Caine wrote:

The main thing I see there is 'raw' SQL. Loading the variables
directly into the script, rather than simply binding them as params. I
have yet to work out a way of converting some of my dynamically
generated SQL into a format that will work with PDO - on any database.
I've only ever used ADOdb and that handles ALL of the parameterizing
of things transparently.

I have no clue what type of dynamically generated SQL you are talking
about. Are you talking about being able to dynamically stick identifiers
into placeholders? This is simply not possible if you are using native
prepared statements. If you emulate them, yes you can, but then you can
might as well use sprintf() with quote() (maybe with a wrapper).

OK this is a key difference between MySQL and other databases - at least
looking at the raw drivers. Firebird ( and PostgreSQL ) can use parameters to
handle the transfer of values to the query.
From pg_query_params manual - "The primary advantage of pg_query_params()
over pg_query() is that parameter values may be separated from the query
string, thus avoiding the need for tedious and error-prone quoting and escaping."

Most projects I work with, build an array of values to be processed, and then
just create a simple SQL query to pass the array to the database.

PDO does wrap this quite nicely, except that BLOB's can only be passed as raw
content? The ability to just pass a BLOB ID means that you only access that
part of a large blob that you need. And most database engines would benefit
from being able to handle BLOB elements independent of the general fetch.
Rather than duplicating and processing several hundred 'k' text blobs, you
just pass the link to the original?

The other problem of cause is length of table and field names and
reserved words. Adding Oracle and MsSQL to the mix, working with raw
upper case table and field names and 31 character name limit
introduces a few extra things to consider over and above just adding
PDO to Drupal ;)

PDO handles some of those, but as said tons of times before, its not an
abstraction layer, its an API unifier. There are PDO based layers like
Doctrine, that give you all the convinience of ADODB (and more ..). They
do however require that the underlying PDO driver is solid.

At any rate .. why bother with PDO when there are "native" extensions?
The point of PDO was not only end user focused, it was also the idea to
one day make it less effort to add new features to all the RDBMS
extensions (for example unicode .. that being said I keep hearing that
PDO HEAD is totally out of sync). It also makes it a lot easier to add a
new RDBMS extension.

The IDEA is still good. It just needs the core tidying up a little more before
it becomes totally practical.

Now if we stick with maintaining the current non PDO extensions, then
you must realize that we are maintaining a lot of redundant code, which
is based on one of the oldest extensions (ext/mysql). Since we do not
have infinite development resources, it would be for the better of any
of the supported RDBMS if it would get its PDO driver up to the same
level as the old extension. As more and more of our userbase is moving
to PHP5 this hopefully will become more and more interesting.

Having finally got to the point where PHP4 IS being end of lifed, then one
of the major stumbling blocks HAS been removed. That is why I AM now coming
back to this - after 2 years - and trying to nail down some of the remaining
problems. I have had to be careful even with the Firebird driver to ensure
that only functions available in PHP4 are used in ADOdb, but it will be nice
to be able to say - that version of project X is the last which will support
PHP4!

NOW we can get on and start looking for PHP6 and proper Unicode support -
Firebird can run DIFFERENT character collations in each field something else
that still needs the native driver to handle ;)

--
Lester Caine - G8HFL

16 years ago by Lukas Kahwe Smith — view source

unread

Lester Caine wrote:

Following on ....

Lukas Kahwe Smith wrote:

Lester Caine wrote:

The main thing I see there is 'raw' SQL. Loading the variables
directly into the script, rather than simply binding them as params.
I have yet to work out a way of converting some of my dynamically
generated SQL into a format that will work with PDO - on any
database. I've only ever used ADOdb and that handles ALL of the
parameterizing of things transparently.

I have no clue what type of dynamically generated SQL you are talking
about. Are you talking about being able to dynamically stick
identifiers into placeholders? This is simply not possible if you are
using native prepared statements. If you emulate them, yes you can,
but then you can might as well use sprintf() with quote() (maybe with
a wrapper).

OK this is a key difference between MySQL and other databases - at least
looking at the raw drivers. Firebird ( and PostgreSQL ) can use
parameters to handle the transfer of values to the query.
From pg_query_params manual - "The primary advantage of
pg_query_params() over pg_query() is that parameter values may be
separated from the query string, thus avoiding the need for tedious and
error-prone quoting and escaping."

But these parameters may only be literals not identifiers. The only
difference in placeholder support is if the placeholders are named
(pgsql, oracle etc.) or not (db2, mysql etc.). PDO (and MDB2, Doctrine
etc. for that matter) support both the named and unnamed in all drivers.

SELECT * FROM ?; // does not work

The reason is technical, the idea behind prepared statements is to have
the database be able to parse and plan the query once. Without
identifiers this would not be possible.

PDO does wrap this quite nicely, except that BLOB's can only be passed
as raw content? The ability to just pass a BLOB ID means that you only
access that part of a large blob that you need. And most database
engines would benefit from being able to handle BLOB elements
independent of the general fetch. Rather than duplicating and processing
several hundred 'k' text blobs, you just pass the link to the original?

Blobs in PDO are implemented via the stream API, so its not only "raw
content". Adding support for blob id's would be a good idea if its not
yet supported.

Speaking of which, another area where PDO standards to reduce duplicate
efforts is documentation, which is still a bit lacking atm (where is the
new Dan?).

regards,
Lukas

16 years ago by Pierre — view source

unread

Hi Lester,

Sorry Pierre I have to disagree there. Most flexible projects are built on
ADOdb, and while you CAN use PDO as an alternative driver, for the best
performance the raw drivers are preferable. I don't see anything to replace
the SQL handling that ADOdb provides although the ADOdbLite does work well if
you do not want a fully featured interface and can do without some of the more
advanced SQL code.

Sorry, I was not clear enough. I did not say that PDO is perfect or
can replace MDB2 or ADODb, it is not its goal.

Being able to build a project for ANY database is nice to
have but requires you manage the SQL as well as the data, and if you are not
building a generic project then you don't need a generic driver.

A common base is already a (very) good start. We obviously need more
and it is unclear how far PHP should go (talking about internals only
here).

I keep being told that the PDO drivers can be extended to include all of the
things already available in the native driver, but the second you do that they
become incompatible, so in addition to the PDO driver you need to also run the
native driver simply to provide the areas NOT covered by PDO. We need a
generic framework that addresses the real problems not one that creates an
artificial lowest common denominator strangle hold :( PDO could evolve into
that, but not with it's current restrictions.

And what do you suggest to improve this situation? One of my
suggestions is to have more DB developers (as in DB internals, if I
can say so :) involved. Oracle and IBM (to name the largest and most
active) understood that and actively participate. I'm not saying that
you do nothing, but I'm not sure that complaining about the bad state
of pdo_firebird is really helpful.

Cheers,
--Pierre

16 years ago by Lester Caine — view source

unread

Pierre wrote:

And what do you suggest to improve this situation? One of my
suggestions is to have more DB developers (as in DB internals, if I
can say so :) involved. Oracle and IBM (to name the largest and most
active) understood that and actively participate.

And IBM have a commercial interest in making it easy for them to sell
licenses, so they support EVERY well used development platform ;) Since a
large percentage of their server users were probably running free copies of
PHP anyway, they saw a support revenue stream?

I'm not saying that
you do nothing, but I'm not sure that complaining about the bad state
of pdo_firebird is really helpful.

See the other post. I am not 'complaining' about the fact that no one is
willing to spend unpaid time on pdo_firebird, just trying to explain WHY. If
the Firebird Foundation had the deep pockets of IBM, Oracle, MySQL etc. then
we would actually PAY someone to do it, but for now it has to have a reason to
be worked on and no one has a reason :(

THAT is why the damage to the php_interbase driver was such a problem!

--
Lester Caine - G8HFL

16 years ago by Pierre — view source

unread

Hi Lester,

Pierre wrote:

And what do you suggest to improve this situation? One of my
suggestions is to have more DB developers (as in DB internals, if I
can say so :) involved. Oracle and IBM (to name the largest and most
active) understood that and actively participate.

And IBM have a commercial interest in making it easy for them to sell
licenses, so they support EVERY well used development platform ;) Since a
large percentage of their server users were probably running free copies of
PHP anyway, they saw a support revenue stream?

Not only that, they also saw customers (no fact to confirm that but
that's obvious) moving away to other DBs because PHP support (naitve,
community, etc.) is better.

I'm not saying that
you do nothing, but I'm not sure that complaining about the bad state
of pdo_firebird is really helpful.

See the other post. I am not 'complaining' about the fact that no one is
willing to spend unpaid time on pdo_firebird, just trying to explain WHY. If
the Firebird Foundation had the deep pockets of IBM, Oracle, MySQL etc. then
we would actually PAY someone to do it, but for now it has to have a reason to
be worked on and no one has a reason :(

THAT is why the damage to the php_interbase driver was such a problem!

I understood that but that does not make pdo support less critical for
firebird's future with PHP. And that's why I disagree with "no reason
to improve it".

--Pierre

16 years ago by Antony Dovgal — view source

unread

I'm not saying that
you do nothing, but I'm not sure that complaining about the bad state
of pdo_firebird is really helpful.

See the other post. I am not 'complaining' about the fact that no one is
willing to spend unpaid time on pdo_firebird, just trying to explain WHY. If
the Firebird Foundation had the deep pockets of IBM, Oracle, MySQL etc. then
we would actually PAY someone to do it, but for now it has to have a reason to
be worked on and no one has a reason :(

It's not about money in the first place.
I started maintaining OCI8 because I was using it quite hard, so I was interested
in OCI8 to be stable and feature-rich to make my own life easier.

For some reason I expect people to do the same when they really need something,
at the very least I expect people to understand that silently waiting (or loudly
complaining in their blogs, that's the same) for a good guy that should come
and do everything for them is not very productive.

--
Wbr,
Antony Dovgal

5.2.4RC1 Released

ls -l /bin/sh

ls -l /bin/sh

sizeof("error_reporting"), "0", 1, ZEND_INI_USER, ZEND_INI_STAGE_RUNTIME); } ZEND_VM_NEXT_OPCODE(); }

./configure 2> err

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Please forgive my ignorance, as I am relatively new to PHP extension building. Is there a document published anywhere that describes how to make extensions unicode safe for php6? Thanks!

Best regards

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

sizeof("error_reporting"), "0", 1, ZEND_INI_USER, ZEND_INI_STAGE_RUNTIME);
}
ZEND_VM_NEXT_OPCODE();
}

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

Please forgive my ignorance, as I am relatively new to PHP extension building.
Is there a document published anywhere that describes how to make extensions unicode safe for php6?
Thanks!

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL