[Mahara-contributors] [Bug 1238373] Re: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys
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 ** Changed in: mahara Status: Confirmed => Won't Fix ** Changed in: mahara/17.04 Status: Confirmed => Won't Fix ** Changed in: mahara Milestone: 17.10.0 => None ** Changed in: mahara/17.04 Milestone: 17.10.0 => None -- 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/1238373 Title: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys Status in Mahara: Won't Fix Status in Mahara 17.04 series: Won't Fix Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1238373/+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
[Mahara-contributors] [Bug 1238373] Re: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys
** Changed in: mahara/17.04 Milestone: 17.04.0 => 17.10.0 -- 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/1238373 Title: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys Status in Mahara: Confirmed Status in Mahara 17.04 series: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1238373/+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
[Mahara-contributors] [Bug 1238373] Re: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys
** Also affects: mahara/17.04 Importance: Low Assignee: Aaron Wells (u-aaronw) Status: Confirmed ** Changed in: mahara/17.04 Milestone: 16.10.1 => 17.04.0 -- 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/1238373 Title: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys Status in Mahara: Confirmed Status in Mahara 17.04 series: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1238373/+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
[Mahara-contributors] [Bug 1238373] Re: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys
** Changed in: mahara Milestone: 16.10.0 => 16.10.1 -- 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/1238373 Title: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys Status in Mahara: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1238373/+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
[Mahara-contributors] [Bug 1238373] Re: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys
** Changed in: mahara Milestone: 16.04.0 => 16.10.0 -- 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/1238373 Title: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys Status in Mahara: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1238373/+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
[Mahara-contributors] [Bug 1238373] Re: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys
** Changed in: mahara Milestone: 15.10.0 => 16.04.0 -- 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/1238373 Title: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys Status in Mahara: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1238373/+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
[Mahara-contributors] [Bug 1238373] Re: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys
** Changed in: mahara Milestone: 15.04.1 = 15.10.0 -- 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/1238373 Title: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys Status in Mahara ePortfolio: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1238373/+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
[Mahara-contributors] [Bug 1238373] Re: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys
** Changed in: mahara Milestone: 15.04.0 = 15.04.1 -- 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/1238373 Title: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys Status in Mahara ePortfolio: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1238373/+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
[Mahara-contributors] [Bug 1238373] Re: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys
** Changed in: mahara Milestone: 1.10.0 = 1.11.0 -- 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/1238373 Title: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys Status in Mahara ePortfolio: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1238373/+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
[Mahara-contributors] [Bug 1238373] Re: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys
** Changed in: mahara Milestone: 1.9.0 = 1.10.0 -- 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/1238373 Title: Mahara sites that have been around since before 1.2 have unique indexes where they should have unique keys Status in Mahara ePortfolio: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1238373/+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
