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

Bug #11692 Value of $db->supports('transactions') changes after query
Submitted: 2007-07-26 08:57 UTC
From: floele Assigned: afz
Status: Closed Package: MDB2_Driver_mysql
PHP Version: 5.1.4 OS: WinXP
Roadmaps: (Not assigned)    

 [2007-07-26 08:57 UTC] floele (Florian Schmitz)
Description: ------------ Hi. I suggest to simply look at my test script, that pretty much says it all. I tried this with the latest stable version, but also with an updated mysql driver from CVS. The actual problem for me is that even though $db->supports('transactions') later returns true, transactions do not work correctly. The test script would continue with $db->supports('transactions') && $db->beginTransaction(); $db->query(...); $schema->updateDatabase(...); $db->inTransaction() && $db->commit(); which results in all queries dropped that occur before $schema->updateDatabase(...). Without beginTransaction() it works fine though. And this function wouldn't be called if $db->supports('transactions') kept the value false. Test script: --------------- <?php require_once 'MDB2.php'; $dsn = 'mysql://root:root@localhost/test'; $db =& MDB2::factory($dsn); var_dump($db->supports('transactions')); // -> no support $db->query("SELECT * FROM anytable"); var_dump($db->supports('transactions')); // now works... ? ?> Expected result: ---------------- $db->supports('transactions') does not change its value Actual result: -------------- $db->supports('transactions') changes from false to true after a query is executed


 [2007-07-28 09:42 UTC] quipo (Lorenzo Alberton)
With the current CVS version, both var_dump() calls in the test script return "false". Can you try again with the CVS version of the package, or post another reproducing script? TIA
 [2007-07-28 10:42 UTC] crodriguez (Cristian Rodriguez)
This is reproducible.. floele script will return false always if the "test" database does not exists. however with this script it will surely be reproducible require_once 'MDB2.php'; $dsn = 'mysqli://root:yourpass@localhost/information_schema'; $db =& MDB2::factory($dsn); if (PEAR::isError($db)) { die($db->getMessage()); } var_dump($db->supports('transactions')); // -> no support $db->query("SELECT table_name FROM tables"); var_dump($db->supports('transactions')); ensure to replace "yourpass" with a valid password. this is reproducile with both mysql and mysqli using the CVS version of MDB2 and it's drivers.
 [2007-07-28 10:43 UTC] floele (Florian Schmitz)
I tried with CVS, does not work. Does the "test" database exist on your system? Because that's what is required for my script to work (in)correctly.
 [2007-07-28 11:19 UTC] quipo (Lorenzo Alberton)
The test database does exist on my machine, and Cristian's test script doesn't produce different results. I still get bool(false) bool(false) What's the problem, exactly?
 [2007-07-28 12:13 UTC] floele (Florian Schmitz)
You'll need a server that supports transactions (I use MySQL 4.1 with InnoDB tables), then the second call will return true. The actual problem though is what I said in my initial comment, if I use transactions it's messed up.
 [2007-07-28 12:41 UTC] floele (Florian Schmitz)
Well, I guess I need to clarify the actual problem so that you don't worry too much about that for now. Transactions *do* work, but the getDefinitionFromDatabase() function does something wrong: It ends with ROLLBACK, but does *not* start with START TRANSACTION, so all queries before the function call are lost as well. I'm not sure whether this is an MDB2 or an MDB2_Schema bug though. In any case a different bug than this one, which should also be fixed.
 [2007-11-10 00:25 UTC] quipo (Lorenzo Alberton)
Igor, do you have a clue? It doesn't seem to be a MDB2 bug...
 [2008-01-30 11:43 UTC] ifeghali (Igor Feghali)
Confirmed with Cristian's test script on: MDB2 2.5.0a2 alpha MDB2_Driver_mysql 1.5.0a2 alpha PEAR Version: 1.7.0RC2 PHP Version: 5.2.5 Output: bool(false) bool(true)
 [2008-02-07 15:45 UTC] afz (Ali Fazelzadeh)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the 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.