Home » Authentication » LiveUser » Bug #355

[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.

[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 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 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 20:38 UTC] kipaten21 at hotmail dot com

That option worked great! Excellent find Juan.