Details
-
New Feature
-
Resolution: Unresolved
-
Major
-
None
-
13.10.9
-
None
-
Unknown
-
Description
Let's imagine you have a main wiki (xwiki) and two subwikis: sub1 and sub2, and the upgrade you perform needs to execute 2 DB Migration called "Migration1" and "Migration2".
Currently the order for executing DB migrations is the following:
1. it executes liquibase migration on xwiki
2. it executes schema migration on xwiki
3. it executes Migration1 on xwiki
4. it executes Migration2 on xwiki
5. it moves to sub1 and do same steps, and then moves to sub2 and do same steps
Problem with this order is that if for some reason Migration2 needs to access a doc on sub1 or sub2, it will perform the access before the schema have been updated, and even before Migration1 has been applied on those docs.
In some rare cases, this might lead to migration errors such as XWIKI-20184.
To avoid this kind of side effect I propose that we change the migration order, to ensure executing the migration one by one on all DB before moving to next migration. So the order would be:
1. it executes liquibase migration on xwiki and sub1 and sub2
2. it executes schema migration on xwiki and sub1 and sub2
3. it executes Migration1 on xwiki and sub1 and sub2
4. it executes Migration2 on xwiki and sub1 and sub2
The big advantage is that developers wouldn't have to think the migration as possibly executed in batches when performing big upgrades, but as executed in small steps like when moving from a stable version to the one just after.
Attachments
Issue Links
- relates to
-
XWIKI-20184 R140401000XWIKI15460 Migration error when migrating from < 14.0 if user belongs to subwiki
- Closed