Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys

[Aaron Wells]

See https://bugs.launchpad.net/mahara/+bug/1238363

In the run-up to 1.2.0, we changed the XMLDB library so that it created proper unique keys. Prior to that, whenever you told it to create a unique key, it actually created a unique index.

Normally this doesn't cause any noticeable difference in behavior. But in bug 1238363 it caused upgrade to crash, because the drop_key() method didn't find the key that was expected. Instead, there was an index.

Potential fixes for this may include:

1. Investigate the difference between a unique key and unique index in MySQL and Postgres to make sure that they really are 100% identical in behavior

2. A one-off upgrade in lib/db/upgrade.php that finds all the "legacy" indexes and drops them and recreates them as keys. However, since sites that have been around since 1.2 tend to be rather large, this might be a slow process.

3. Make drop_key() more robust, so that if there is no key by that name on that table, it just looks for an index by that name on that table. This has the potential to be an unexpected side effect and thus cause problems of its own, but I think it'd be pretty rare for someone to create a key and an index with the same name, on the same table. It could also print a debug() message when silently doing this substitution.

[Robert Lyon (robertl-9)]

Point 3 has been fixed by https://reviews.mahara.org/#/c/3443/

As for point 1 and 2 - we don't support direct upgrade from anything lower than 1.6 (currently) and will soon be 15.04

So anyone needing to upgrade from before 1.2 will need to specialist help and can read this bug report for advice.

So will not fix as part of core code