-
Bug
-
Resolution: Timed out
-
Low
-
None
-
6.1
-
6.01
-
Severity 3 - Minor
-
-
Currently it does this:
private void createIndex(final DatabaseUtil dbUtil, final ModelEntity issueEntity, final ModelIndex projNumIndex) { final String error = dbUtil.createDeclaredIndex(issueEntity, projNumIndex); if (error != null) { log.error("Update failed. Read more about possible reason: " + "https://confluence.atlassian.com/display/JIRAKB/Upgrading+To+JIRA+6.1+Fails+Due+To+Duplicate+Issue+Keys"); throw new RuntimeException("Could not create index: " + error); } } private void dropIndex(final DatabaseUtil dbUtil, final ModelEntity issueEntity, final ModelIndex projNumIndex) { final String error = dbUtil.deleteDeclaredIndex(issueEntity, issueEntity.getIndex(projNumIndex.getName())); if (error != null) { throw new RuntimeException("Could not drop index: " + error); } }
The problem is that upgrade tasks that use DDL need to be much more tolerant of unexpected state, because a restore can make the upgrade task history inconsistent with the expected DDL state. If I restore an instance that had not run that upgrade task, then it will attempt to run it and it will fail because the index was already deleted. Restoring a backup does not restore the previous state of the schema.
In this particular case, since the one it creates has the same name, this is less likely. However, if it ever has data with a duplicate issue and therefore fails to recreate the unique index, it will fail from then on.
- relates to
-
JSWSERVER-16473 Reindex All FAILED - Caused by null issuenum entry in jiraissue table
- Closed
-
JRASERVER-69826 Add null constraint for issuenum column to jiraissue table
- Gathering Interest
- clones
-
JDEV-32877 Loading...