Change Details

We have full export/import support for Flow, but it was designed more for right to fork (third-party wikis being able to restore the whole wiki) and offline analysis (research, etc.) We did not consider the use case of a transwiki within a farm, and there is an issue. All of the workflows are in the same database (except private wikis), and the import process preserves UUIDs. That means when you import a board that's already somewhere on the cluster, it will cause ID collisions. I think the solution is actually not as hard as it sounds, though: * Add centraluserid to the export if this is an attached wiki (forget how to check that). * Add a FlowBackupReader subclass of BackupReader (currently we use the standard core import script/class). Add a --transwiki , which means that this is a transwiki (copy) between two wikis on the same farm (meaning CentralIdLookup works). * In transwiki mode, you don't import the corresponding core pages to the Flow board you're transwiki-ing. Instead, the transwiki mode creates them for you. * Whenever an ID is encountered, it is mapped to a new equivalent ID using HistoricalUIDGenerator. This mapping is preserved and reused. * In handleBoard and handleTopic, we also create the board and topic core pages using ensureFlowRevision (the same way we normally create them). (In the current importer, we only do this for boards, which is inconsistent. I don't think it's necessary for non-transwiki since we assume you're also doing a core import. If it were, we would also need it for topics.). * Map all the user names to local user IDs using CentralIdLookup.

We have full export/import support for Flow, but it was designed more for right to fork (third-party wikis being able to restore the whole wiki) and offline analysis (research, etc.) We did not consider the use case of a transwiki within a farm, and there is an issue for WMF (and any other farm that used $wgFlowCluster like WMF). All of the workflows are in the same database (except private wikis), and the import process preserves UUIDs. That means when you import a board that's already somewhere on the cluster, it will cause ID collisions. I think the solution is actually not as hard as it sounds, though: * Add centraluserid to the export if this is an attached wiki (forget how to check that). * Add a FlowBackupReader subclass of BackupReader (currently we use the standard core import script/class). Add a --transwiki , which means that this is a transwiki (copy) between two wikis on the same farm (meaning CentralIdLookup works). * In transwiki mode, you don't import the corresponding core pages to the Flow board you're transwiki-ing. Instead, the transwiki mode creates them for you. * Whenever an ID is encountered, it is mapped to a new equivalent ID using HistoricalUIDGenerator. This mapping is preserved and reused. * In handleBoard and handleTopic, we also create the board and topic core pages using ensureFlowRevision (the same way we normally create them). (In the current importer, we only do this for boards, which is inconsistent. I don't think it's necessary for non-transwiki since we assume you're also doing a core import. If it were, we would also need it for topics.). * Map all the user names to local user IDs using CentralIdLookup.

We have full export/import support for Flow, but it was designed more for right to fork (third-party wikis being able to restore the whole wiki) and offline analysis (research, etc.) We did not consider the use case of a transwiki within a farm, and there is an issue for WMF (and any other farm that used $wgFlowCluster like WMF). All of the workflows are in the same database (except private wikis), and the import process preserves UUIDs. That means when you import a board that's already somewhere on the cluster, it will cause ID collisions. I think the solution is actually not as hard as it sounds, though: * Add centraluserid to the export if this is an attached wiki (forget how to check that). * Add a FlowBackupReader subclass of BackupReader (currently we use the standard core import script/class). Add a --transwiki , which means that this is a transwiki (copy) between two wikis on the same farm (meaning CentralIdLookup works). * In transwiki mode, you don't import the corresponding core pages to the Flow board you're transwiki-ing. Instead, the transwiki mode creates them for you. * Whenever an ID is encountered, it is mapped to a new equivalent ID using HistoricalUIDGenerator. This mapping is preserved and reused. * In handleBoard and handleTopic, we also create the board and topic core pages using ensureFlowRevision (the same way we normally create them). (In the current importer, we only do this for boards, which is inconsistent. I don't think it's necessary for non-transwiki since we assume you're also doing a core import. If it were, we would also need it for topics.). * Map all the user names to local user IDs using CentralIdLookup.