Looking at this forum post https://mahara.org/interaction/forum/topic.php?id=5986&offset=0&limit=10 ...
It occurs to me that there's a problem in our schema correction code. We're adding foreign keys to existing tables, but we didn't first check to see whether the tables have data that will fit that foreign key. If they have bad data, then this upgrade script will error out and prevent them from upgrading. And since these missing schema elements are not vital, we don't want their failure to block upgrade. We should have put a "catch (SQLException $e)" block around each attempt to add a foreign key, unique index, and/or primary key, or another other schema element that will fail if their data isn't clean. :-P I'll spin off another bug for that... -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1174623 Title: Correct schema drift during 1.0 -> 1.8 upgrades Status in Mahara ePortfolio: In Progress Status in Mahara 1.8 series: In Progress Status in Mahara 1.9 series: In Progress Bug description: We seem to get a lot of bug reports on the forum from people having issues after upgrading from pre-1.5 Mahara instances up to the latest. It seems that the upgrade scripts do not generate a database schema which is consistent with what you'd get from a clean 1.7 installation. If we want people to update to the latest version of Mahara (and we do!) then we need to make sure that the upgrade process works properly. So, we should test the upgrade process from each of the old versions of Mahara into master, and if it doesn't produce exactly the same DB schema as a fresh install, we need to correct the master upgrade scripts to solve this. Of course, there's also the matter of data in those tables getting messed up, but that's harder to recognize and fix. We could test for it partway, by making sure we upgrade a non-empty Mahara instance (something with at least a few users, pages, institutions, auth methods, etc). It might also be a good idea to add a tool that compares the schema against all of the install.xml files, so that users can tell whether they have a problem or not. Not worth writing one from scratch, but Moodle 2 has a script for copying a database, and one of its steps is to check the schema against all the XMLDB files, so we may be able to use that. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1174623/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
