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

Bug #10598 MDB2::singleton() doesn't always work
Submitted: 2007-04-03 17:08 UTC
From: fornax Assigned: fornax
Status: Closed Package: MDB2 (version 2.4.0)
PHP Version: 4.3.11 OS: Centos 4.3, Apache 1.3
Roadmaps: (Not assigned)    
Subscription  


 [2007-04-03 17:08 UTC] fornax (Andrew Hill)
Description: ------------ Oooh, a nasty one. For whatever reason, if you create a connection to a database server without specifying a database name (to connect to the default database for that database type, eg. 'template1' for PostgreSQL) so that you can do things like create a database that doesn't exist yet, and then, after doing that, you want to create a new MDB2 connection to the newly created database, the MDB2::singleton() method doesn't work. This is because it uses the built in array_diff() to compare the DSN for the new database connection with the previously used DSN (to the default database) - but the database name is set to the boolean "false", which doesn't result in the comparison failing - so the singleton() method returns the old connection to the default database! (No, I don't know why array_diff doesn't work - the PHP manual says is should, as far as I can read it. But it doesn't appear to. *shrug*) Using the built in array_diff_assoc() resolves this issue. Test script: --------------- --- MDB2.php (revision 5540) +++ MDB2.php (working copy) @@ -487,7 +487,7 @@ for ($i=0, $j=count($keys); $i<$j; ++$i) { if (isset($GLOBALS['_MDB2_databases'][$keys[$i]])) { $tmp_dsn = $GLOBALS['_MDB2_databases'][$keys[$i]]->getDSN('array'); - if (count(array_diff($tmp_dsn, $dsninfo)) == 0) { + if (count(array_diff_assoc($tmp_dsn, $dsninfo)) == 0) { MDB2::setOptions($GLOBALS['_MDB2_databases'][$keys[$i]], $options); return $GLOBALS['_MDB2_databases'][$keys[$i]];

Comments

 [2007-04-03 20:55 UTC] quipo (Lorenzo Alberton)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.