Hi @Kusal
I was wondering what Atlassian’s plans are for the ContentPropertyManager (not ConfluencePropertySetManager). In Confluence 10 it seems you’ve just reduced the API by removing the accessors for text properties but otherwise it seems to remain fully functional.
In contrast to that the ConfluencePropertySetManager has been announced to be read-only in 10.x and scheduled for removal in Confluence 11.
I understand that the overall goal here is to get rid of the OS propertyset infrastructure eventually.
Some of our apps store a lot of properties in this storage (10-15 per Confluence page). If you remove OS propertyset in 11.0, will you also automatically migrate the existing data to a new storage, similar to what you have done with Bandana?
We also use the PropertySet.getKeys() API for listing property keys in scenarios where they are dynamic and we can’t hardcode them. It doesn’t seem like there is any replacement API for this yet, but we’d need it latest when the PropertySet APIs are finally removed.
Wouldn’t it therefore make sense to introduce something like ContentPropertyManager.getPropertyKeys(ceo) in Confluence 10.0 so that apps can switch as quickly as possible to only the ContentPropertyManager API? Similar to what you’ve done in the Bandana->PluginSettings transition, where you’ve added a similar getKeys method.
Even if we were to later on manually migrate properties in a plugin upgrade task to a different storage, we’d also need such a key-iterating API.
Tbh. I really hope it doesn’t come to this, because a PluginUpgradeTask migrating properties of millions of pages (I know of several such big instances) using the current high-level APIs will run a very long time …
Thanks,
Jens