Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.16.14

Bug #355 Another Oracle compatibility issue with get* methods
Submitted: 2003-12-04 19:47 UTC
From: kipaten21 at hotmail dot com Assigned: arnaud
Status: Closed Package: LiveUser
PHP Version: 4.3.3 OS: ANY
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 27 - 7 = ?

 
 [2003-12-04 19:47 UTC] kipaten21 at hotmail dot com
Description: ------------ The following methods... LiveUser_Admin_Perm_DB_Common::getApplications() LiveUser_Admin_Perm_DB_Common::getAreas() LiveUser_Admin_Perm_DB_Common::getLanguages() LiveUser_Admin_Perm_DB_Common::getRights() LiveUser_Admin_Perm_Container_DB_Complex::getGroups() take an $options array that accepts, among other things, booleans to determine whether or not to retrieve dependency data for each section. For example.... LiveUser_Admin_Perm_DB_Common::getAreas( array( 'where_area_id' => $area_id, 'with_applications' => true ) ); will return the application data for the specified area. The code that does this in getAreas().... $_areas = array(); foreach ($areas as $key => $value) { $id = $value['area_id']; $_areas[$id] = $value; if (isset($options['with_applications'])) { $_areas[$id]['application'] = $this->getTranslation( $value['application_id'], LIVEUSER_SECTION_APPLICATION ); if (DB::isError($_areas[$id]['application'])) { return $_areas[$id]['application']; } }; } The line that gets the translation for the application passes the application_id from $value['application_id']. The problem is, $value is a key=>value pair from the $areas variable, which is a DB result object that stores the query results in an associative arrary... $areas = $this->dbc->getAll($query, null, DB_FETCHMODE_ASSOC); However, oracle's column/table names are always uppercase, so the asscociative array should actually be accessed via $value['APPLICATION_ID']. Currently, getTranslation() returns empty because the db result didn't have a column called 'application_id', only 'APPLICATION_ID'. This behavior is concurrent across all the methods listed above. This problem is obviously restricted to Oracle. I do not have an immediate solution that would enable this code to work independent of the backend database, however I'm sure somthing can be done.

Comments

 [2003-12-04 20:08 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2003-12-04 20:11 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2003-12-04 22:49 UTC] kipaten21 at hotmail dot com
Confirmed. I am using a cvs co from Monday with Oracle.
 [2003-12-05 06:26 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2003-12-05 19:22 UTC] kipaten21 at hotmail dot com
$Id: DB.php,v 1.13 2002/07/02 15:19:49 cox Exp $
 [2003-12-05 20:20 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2003-12-05 23:15 UTC] kipaten21 at hotmail dot com
Upgraded. Same problem.
 [2003-12-08 15:30 UTC] juan dot caicedo-carvajal at insa-lyon dot fr
Ithink that the cause of the bug is that Oracle 'always' returns the keys of an associative array in upper case, so we will have to make something with the result of the query. In PHP 4.2 the function array_change_key_case was introduced and that's exactly the solution that PEAR uses. In the class DB_oci8 the function is called in the method fetchInto (DB/oci.php [version 1.10] lines 194 - 211 ). But notice that the function will be called only if the attribute $this->options['optimize'] has the value 'portability'. The default value is 'performance' (DB/common.php [version 1.21] lines 91 - 102), so I think that is the cause of problem. Indeed, i see that in the LiveUser_Auth_Container_DB class, in the class constructor we have the following: (lines numbers based on version 1.33) 128: if (!DB::isError($this->dbc)) { 129: $this->init_ok = true; 130: } I think that the following will solve the problem: 128: if (!DB::isError($this->dbc)) { 129: this->init_ok = true; 130: $this->dbc->setOption('optimize','portability'); 131: }
 [2003-12-08 15:59 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2003-12-08 20:38 UTC] kipaten21 at hotmail dot com
That option worked great! Excellent find Juan.
 [2003-12-08 20:41 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!