Description: ------------ Hi. I'm trying to use MDB2 Schema to keep the database of a web application up-to-date. So I basically have an XML file that contains the most current database definition. On each database change, every user of the application simply "runs" (using a PHP script) the updated XML file to get the database up-to-date. Occasionally, columns need to be renamed. This is were the problem starts. If I add a <was> element and the XML file is executed, the column is renamed as expected. However, if I later add more changes to the XML file and the XML file is run again, it complains that the <was> column doesn't exist anymore (because it has already been renamed). This is correct, but it should not abort upgrading the database in this case (or give an option to ignore this error) since it's not critical at all. Thanks in advance for any help on that matter. Expected result: ---------------- updateDatabase() ignores missing <was> column Actual result: -------------- updateDatabase() throws a PEAR error and thus does not finish the database upgrade

I attached a patch so that you can see what is needed, I'd be happy if you added this or a similar solution for the next release.

Hello Florian ! Thank you for taking your time for submitting a patch. Thats a weird behavior since parseDatabaseDefinitionFile() should call MDB2_Schema::Validate that in turn should set the 'was' property to the field name everywhere it is missing. This way you won't get any error as the if condition would be false. Can you please provide your test script ?

Thanks for your reply. I do in fact not call this function, the full script looks like this: require_once 'MDB2/Schema.php'; $schema =& MDB2_Schema::factory($db); $schema->setOption('force_defaults', false); $previous_schema = $schema->getDefinitionFromDatabase(); $res = $schema->updateDatabase($path_to_file, $previous_schema, array('db_prefix' => $conf['database']['dbprefix'], 'db_name' => $conf['database']['dbname'])); Do you need a fully working self contained test script to reproduce the problem or does this code hint at the possible problem?

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.

Thanks for the fix, I can confirm that it works correctly now.