Package com.atlassian.confluence.upgrade.upgradetask

Class DropAndUpdateContentIndexesUpgradeTask

  • All Implemented Interfaces:
    BackupSupport, DatabaseUpgradeTask, UpgradeTask, UpgradeTaskInfo, org.springframework.beans.factory.Aware, org.springframework.beans.factory.BeanNameAware
    public class DropAndUpdateContentIndexesUpgradeTask
extends AbstractUpgradeTask
implements DatabaseUpgradeTask
    This upgrade task is to fix index rebuilding performance issues mainly caused by some low cardinality indexes. The databases (mysql5.5, oracle, postgres9.3) may choose these indexes for execution of some query sql, which will lead to extreme slowness during the long-running task. More details at https://jira.atlassian.com/browse/CONF-41010 It is also observed (specifically on oracle) that the column order of multi-column index may mislead the query optimizer as well if the low cardinality column is placed before other columns. The solution is to drop the low cardinality indexes and adjust(drop & create) column order for multi-column indexes.
    Since:
    6.0.3

    • Constructor Detail

      • DropAndUpdateContentIndexesUpgradeTask

        public DropAndUpdateContentIndexesUpgradeTask​(DdlExecutor ddlExecutor)

    • Method Detail

      • runOnSpaceImport

        public boolean runOnSpaceImport()
        Description copied from interface: BackupSupport
        Returns true if an older Space can't be imported in a new instance without running this task. For example:
        • A task updating macro names in the BodyContent table would be blocking.
        • Tasks which updates data related to the space would be blocking.
        • A task upgrading the user table wouldn't be blocking.
        • Adding a mandatory column on space-related content breaks space import

        Note that tasks don't run on space import yet, so we just reject the import in this case.

        Specified by:
        runOnSpaceImport in interface BackupSupport

      • breaksBackwardCompatibility

        public boolean breaksBackwardCompatibility()
        Description copied from interface: BackupSupport
        Returns true if a new export can't be imported in an older instance.

        Breaking compatibility means a snapshot of the new version will not work at all with the previous version. For example:

        • A destructive operation (Some data is replaced by another) breaks backwards compatibility
        • Adding a optional column does NOT break backwards compatibility
        • Data is copied to another column doesn't breaks backwards compatibility
        • A build number incrementation doesn't breaks backwards compatibility
        The best way to test is whether a newer export can be imported (with fully working features) in an older instance.
        Specified by:
        breaksBackwardCompatibility in interface BackupSupport