Home » Database » DB » Bug #6730
PEAR::DB is not compliant with PHP 5
Details
| Submitted | 2006-02-08 23:24 UTC |
|---|---|
| From | caaguado at xcentra dot com |
| Assigned | danielc |
| Status | Bogus |
| Package | DB |
| PHP Version | 5.1.2 |
| OS | Windows XP |
| Roadmaps | (Not assigned) |
Comments
[2006-02-08 23:24 UTC] caaguado at xcentra dot com
Description:
------------
When using PEAR::DB 1.7.6 with error_reporting level E_ALL
(2047, I'm TOTALLY sure about this, since it's the value
set in php.ini, plus I set it again to E_ALL in my
application), a lot of PHP 5 compatibility error
notifications are registered in the application's
system log (I use PEAR::Log for logging).
All these errors are related to lack of alignment of
PEAR::DB with PHP 5 (at least with PHP 5.1.2). A list of
error types by file comes next (it's not a comprehensive
list though, but a list including the type of errors that
appear. They should be fixed in all the files that make the
PEAR::DB package up):
DB.php:490 >> Assigning the return value of new by reference is deprecated
DB.php:540 >> Non-static method DB::parseDSN() should not be called statically
DB.php:571 >> Non-static method DB::isError() should not be called statically
DB.php:610 >> is_a(): Deprecated. Please use the instanceof operator
DB.php:944 >> var: Deprecated. Please use the public/private/protected modifiers
Additionally, the DB::connect() also generates the
following error:
test.php:188 >> Non-static method DB::connect() should not be called statically
I've taken a look at Bug # 6015 and issuer
php-bug at sm dot msk dot ru is right reporting these
errors. Since I'm providing feedback about a higher
number or errors, please don't answer this bug report
telling that it's a duplicated copy of Bug # 6015 or
Bug # 4868.
Thanks a lot for your support !!
[2006-02-09 00:20 UTC] caaguado at xcentra dot com
Hi, it's me again. I just found out that Apache's error log
gets also flooded with error messages like the following:
[Thu Feb 09 01:10:31 2006] [error] [client 127.0.0.1] PHP Notice: Undefined variable: priority in c:\\apache\\htdocs\\dev\\pkgs\\DB.php on line 490\n
Execution of the script using PEAR::DB hangs for a long time
and the Apache returns a "500 Internal Server Error".
[2006-02-09 01:33 UTC] caaguado at xcentra dot com
Hi Daniel,
Yes, you're right regarding the DB.php file version. I'm
also using v1.80, but I added some comments in the upper
part of the file, so line 490 is line 470 in the v1.80
original code.
Apart of the warnings appearing in the log, the main
problem, I guess, are all the "Undefined variable: priority"
entries in Apache's error log, which make PHP hang.
Do you mean the set_error_handler() documentation in the
PHP Manual at php.net? The only new specific parameter for
PHP 5 is "error_types", and it is used for error filtering.
If you're recommending me to use that parameter, I still
think it's not a "clean solution", since it's not a
question of ignoring the errors, but of fixing them instead,
don't you think? IMHO, if the syntax if not fully compliant
to PHP 5 in some lines of the code, then they should be
modified... ;-) Please correct me if I'm wrong!
[2006-02-10 00:17 UTC] caaguado at xcentra dot com
Hi Daniel,
1.
No, my system is not messed up. It's something a bit
strange, but I think there is an explanation:
According to this: http://pdxphp.org/node/72, it seems that
the "PHP Notice: Undefined variable: priority in" entry in
Apache's error log is related to using PHP's call_user_func
function.
Right after connecting with the DB with DB::connect(), I
set a custom callback error handler for DB errors with the
following code:
DB_common::setErrorHandling(PEAR_ERROR_CALLBACK, 'ce_DB_common_error_handler');
setErrorHandling() is inheritated from the core PEAR class.
Since class DB_Error extends PEAR_Error, each time an
instance of class DB_Error is used, and since I set error
handling to PEAR_ERROR_CALLBACK, PHP's call_user_func()
is used to invoke my ce_DB_common_error_handler() function.
You can check this behaviour in the PEAR_Error class code
in PEAR 1.4.6.
I've verified that every single "PHP Notice: Undefined
variable: priority in" entry corresponds with a line
in any of the PEAR::DB files in which a "var" keyword
is used.
So, as a summary, each time the deprecated "var" keyword
is used in PEAR::DB, I see one entry in my application's
error log of this type:
"var: Deprecated. Please use the public/private/protected modifiers"
and one in Apache's error log of this type:
"PHP Notice: Undefined variable: priority in (...)"
Both notifications are pointing to the same fact: A
deprecated keyword is still being used in PEAR::DB !
2.
So, what a long journey to end up saying that "PEAR DB is
a PHP 4 class. It will not ever be made into a PHP 5
class". If this is final, please be fair a delete the
"DB is compatible with both PHP 4 and PHP 5" line at the
end of the package description.
I understand that maintaining two development branches
(as, for example, for the PHPUnit / PHPUnit2) is a lot
of work. It's even OK to say that it will always be a
PHP 4 class. But claiming to be PHP 5 compatible when
the package throws a lot of errors when used with PHP 5
is nor professional nor fair, specially when fixing
things like those deprecated modifiers is only a
question of searching and replacing throughout the
code tree.
Please remove the PHP 5 compatibility statement, because
it's simply not true !
3.
I think that the "That is all. No need to reply."
comment wasn't very nice. If you're so much cleverer
than the average guy (me, in this case), why don't
you simply turn off the bug tracking system for
this packege?