PluginSettings how to manage?

[Igor Slinko]

Hi, as I can see, there is an option to delete value, defined by key, but how can I delete all settings connected to my plugin, or how can I iterate over them?

How can I delete all settings when end-user uninstalls/disables my plugin? I tried to listen to onPluginDisabled event, but I assume, it is called after actual disabling ((

[cofarrell · Accepted solution]

Hi Igor,

It was intentionally designed this way, so that if someone disabled a plugin and then reenabled then data wouldn't be accidentally lost. If the repository is deleted all the settings are removed. UPDATE 5/1/2015: It seems you need to use an event listener to delete your settings when the repo is deleted. See https://answers.atlassian.com/questions/11966535

You can iterate over all the keys by calling Settings.asMap().keySet().

Is there any particular reason you want to remove the settings?

Charles

[Igor Slinko]

I see some cases when I need to delete all settings when disabling plugin. Actually I hoped you will point some methods to handle plugin disabling. For example, I need to kill a job that I scheduled.

"If the repository is deleted all the settings are removed" - is it some hook-magic? I suppose nothing would be deleted in regular plugin, case keys in PluginSettings are not defined by repo.

PS: from this point I will start my questions with "Hi Charles" )))

[Igor Slinko]

It's surprising, but I do not have enough karma to edit my own comment 0_o

How bad is to have trailing settings? for example I want to notify user several times for some issue, and I'm keeping some settings for this notifications. But when issue is solved I don't need these settings, so how bad is to hold them as trash?

[Igor Slinko]

Hey, I think i realised, what you ment speeking of repo deleting... repositoryHookService right?

[Igor Slinko]

For PluginSettings class it doesn't work ( Should I convert my plugin to hook and use RepositoryHookService or there is another way too keep settings for plugin?

For example, is it ok to serialize map of settings and keep it in one single key in PluginSettings?

[cofarrell]

Hi Igor,

For example, I need to kill a job that I scheduled.

You can implement a spring DisposableBean on your component which can then perform the appropriate shutdown. This will be called as your plugin is being disabled, is the best place to cleanup.

How bad is to have trailing settings? for example I want to notify user several times for some issue, and I'm keeping some settings for this notifications.

Well it's obviously not ideal. If you're using PluginSettings it is your job to cleanup. Sorry, I got confused, I thought you were talking about hook settings, which are something else entirely and only useful for hooks.

For example, is it ok to serialize map of settings and keep it in one single key in PluginSettings?

Depends on how big the settings are. You can also use a different set of keys (ie plugin.id.foo = abc, plugin.name.bar = xyz, etc), if you just need a key value store. Again, please make sure you clean up the settings afterwards.

Sorry for the confusion.

Charles

[cofarrell]

Igor,

They're stored in the plugin_setting database table.

Why can't you remove the setting with the remove(key) method?

How is your settings stock full?

Charles

[Igor Slinko]

I'll try this Bean, thanks

I'm wondering how to find out the max size of this map...

And I've just hit the case, when I need to clean up all my settings. I've ran my plugin to test it on the production server. And now my settings stock is full . I wish I could delete them after testing. The only thing I came up with is to change key generation func, so the old keys would be out of use. It's obviously bad solution, but I can't see alternatives ( Is there some file on the server, where settings are keeping?

[Igor Slinko]

>>Why can't you remove the setting with the remove(key) method?

Case they are defined by user and pull request. I've stored like 500 different settings keys ) and now I need to rewrite my plugin to do the same job, but deleting keys instead of keeping them.

By "full" I ment, that values in these keys have influence on plugin behaviour. So I need them to be deleted, if I what plugin to behave like it was ran for the first time.

Maybe I'll go with manualy editing dabatase...

[Igor Slinko]

It's sad, but there is not file named plugin_setting or something connected to plugin and settings. Here is the list of all (not soy, js or less) files in 'target', that have 'setting' word in them:

./container/tomcat7x/cargo-stash-home/webapps/stash/static/feature/project/project-settings-form

./container/tomcat7x/cargo-stash-home/webapps/stash/static/layout/project-settings

./container/tomcat7x/cargo-stash-home/webapps/stash/static/layout/repository-settings

./container/tomcat7x/cargo-stash-home/webapps/stash/static/page/project/settings

./container/tomcat7x/cargo-stash-home/webapps/stash/static/page/repository/settings

./stash/webapp/static/feature/project/project-settings-form

./stash/webapp/static/layout/project-settings

./stash/webapp/static/layout/project-settings/project-settings.soy

./stash/webapp/static/layout/repository-settings

./stash/webapp/static/page/project/settings

./stash/webapp/static/page/repository/settings

[cofarrell]

Ahhh. 'plugin_setting' is the name of database table. Not sure why you're looking for a file with that name...

Be very careful if you do go and decide to edit the DB manually. Please backup your data first.