Class SplitJournalUpgradeTask

  • All Implemented Interfaces:
    BackupSupport, DeferredUpgradeTask, UpgradeTask, UpgradeTaskInfo, org.springframework.beans.factory.Aware, org.springframework.beans.factory.BeanNameAware

    public class SplitJournalUpgradeTask
    extends AbstractDeferredRunUpgradeTask
    Does 2 things:
    • Updates the journalentry table to move items from main_index to change_index if they are:
      • DELETE_CHANGE_DOCUMENTS
      • DELETE_CHANGE_DOCUMENTS
      • ADD_CHANGE_DOCUMENT
      • REBUILD_CHANGE_DOCUMENTS
    • writes the most recent id from the main_index journal to the change_index journal so that the change_index will continue at the same item as the main_index as the {@see SplitIndexUpgradeTask} will already have copied the relevant changes to the new index.
    Since:
    7.9.0
    • Method Detail

      • doDeferredUpgrade

        public void doDeferredUpgrade()
                               throws Exception
        Description copied from interface: DeferredUpgradeTask
        Run the upgrade that was deferred by an earlier call to doUpgrade.
        Throws:
        Exception
      • 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.

      • 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.
      • createChangeTasks

        protected void createChangeTasks​(JournalEntryType journalEntryType,
                                         Function<JournalEntry,​ConfluenceIndexTask> changeTaskCreator)
        Create tasks to be written to the change index for all tasks that were previously writing both change and content documents