Hey Kusal, thanks for the hint with the SpacePropertyService. Unfortunately it is not possible to get all space keys with the given property key. fetchMany requires a space key. Do you have plans to change that? How can I implement it without the JPAQueryFactory?
Such queries work correctly only for âdefinedâ names (like ConfluenceBandanaRecord etc), but is there any reliable way to query tables AO_****?, so far I have used createNativeQuery, but it does not give 100% certainty of operation and problems appear for some configurations 
Example: âSELECT * FROM AO_ED669C_TOTP_USER_ENROLLMENT WHERE USER_KEY = âUSER_KEYââ
The following might be suitable: com.atlassian.activeobjects.external.ActiveObjects#findWithSQL.
1 Like
Hi @Kusal
Basically, what you sent will work for tables/classes built into the plugin, but what if I wanted to retrieve data from another add-onâs AO? ⊠I donât have any of my tables defined in AO but I would like to download other
invoking ActiveObjects before <ao> configuration module is enabled or plugin is missing an <ao> configuration module. Note that scanning of entities from the ao.model package is no longer supported.
I donât believe thatâs supported
Thanks @Kusal - perhaps you are planning to implement such a solution?, in Jira, there is no issue with querying any tables
Unfortunately, weâve currently no plans to support cross-plugin querying but you may open a feature request.
During migration to SAL PluginSettings I realised that com.atlassian.sal.confluence.pluginsettings.ConfluencePluginSettings.get(String key) method is using bandanaManager.getValue that is internally uses lookup and there is no way for us to change that. In the past we used bandanaManager consistently with no lookup and for us it has to stay that way. What can be done about that?
The javadoc is telling actually the opposite:
âGets a setting value. The setting returned should be specific to this context settings object and not cascade the value to a global context.â
1 Like
Itâs fixed in 10.0.
The new PluginSettingsFactory implementation is complete - refer to this reply for further details.
The reason is probably, that the Bandana table is a total mess and if you want to fix some problem in the database or even find it, you are lost, except someone tells you some magical query. It furthermore breaks easily. Bandana context error is very common. The robustness tends to be zero. With the use of AO tables you can at least narrow down the problem.
Iâm an admin, not developer and I welcome this.
When importing a space from Confluence 9 into Confluence 10, all space-specific Bandana values are written to the BANDANA table. They also appear in the PLUGIN_SETTING table. However, values that are too long are not copied into PLUGIN_SETTING.
The question for us as vendors is: what should we do in this situation? Itâs not entirely clear to me whether Confluence now relies exclusively on PLUGIN_SETTING and whether BANDANA merely serves as a kind of backup. I couldnât find any references to this in the Confluence source code. The Preparing for Confluence 10 page also didnât mention anything about handling importsâonly about the one-time upgrade to Confluence 10. But those upgrade tasks do not run when a space is imported.
Iâd appreciate your thoughts on this @Kusal
2 Likes
I tried testing a migration of a space where some Bandana entries are longer than 99,000 characters.
Our approach in the migration tasks is to split these entries into multiple chunks and store them with numbering.
Itâs important to be aware that a call like
pluginSettingsFactory.createSettingsForKey("myspaceKey")
.put("myKey", "my-super-long-value-with-exact-99000-chars")
will fail, because the 99,000-character limit applies to the serialized value that is created in the putCustomTypedValue method in ConfluencePluginSettings.
I hope this helps someone, because otherwise some entries will be missing in the new PLUGIN_SETTING table after migration.
1 Like
@Kusal do you have any knowledge on how space imports are treated?
Thx, Daria
Plugins should indeed ignore the BANDANA table. There remains some Confluence internal code which relies on Bandana however this code will be migrated before Bandanaâs upcoming permanent deletion.
There is currently no mechanism to enable a com.atlassian.sal.api.upgrade.PluginUpgradeTask to run on space import. This is because we do not expect plugins to store data against a space key. However, if your plugin does this and you require this capability, you may be able to trigger your migration code by registering an event listener for com.atlassian.confluence.event.events.admin.AsyncImportFinishedEvent instead.