Confluence 10.0 release EAP is available now

That is correct.

If all your Bandana data abides by the supported types and limits, you can rely on this migration and no further upgrade task is required.

This scenario should not be possible. In Confluence 9.x, BandanaManager and PluginSettingsFactory are backed by the same table. In Confluence 10.0, a new table will be introduced and all compatible data copied across during upgrade (after which the old table will become read-only).

If you’ve defined a plugin upgrade task which executes in 9.x which migrates unsupported data types to supported ones - then this migrated data is still written back to the Bandana table, and thus will be retained during the new table migration in 10.0.

Alternatively, if you have defined a plugin upgrade task which executes in 10.0, it will run after the new table creation/migration. This should also not be an issue as your upgrade task will simply overwrite the data from the default migration.

In summary:

  • If your plugin only writes supported data types to Bandana, no plugin upgrade task is required. Simply migrate your BandanaManager code usages to PluginSettingsFactory.
  • If your plugin writes unsupported data types to Bandana, define a plugin upgrade task to migrate such data to a supported type or another data store entirely. This plugin upgrade task can be configured to run in any Confluence version. Then migrate BandanaManager code usages to the destination data store(s) you have chosen in your upgrade task.

Please note that the new PluginSettingsFactory table is not yet present in the EAPs. You may follow the EAP changelog for when it is available, after which you will able to do further testing.

2 Likes