Adding a method `get_like` to PluginStore class

[angus (Angus McLeod)]

@fzngagan

If a plugin has two or more entities they want to store say apples and oranges, they’ll store the data as apple_1, apple_2… and orange_1, orange_2 from a plugin names fruits.

The pattern is to use the key field in the plugin_store_rows table to store both a namespace and a unique identifier, i.e.:

<namespace>_<id>

This pattern is seen less in core Discourse plugins these days with a general decline in the use of PluginStore for example:

• OAuth2 Basic Plugin used it to store associated account data until we migrated it to user_associated_accounts.

• Poll plugin used it prior to the migration to it’s own table.

However it is still used in places, including the core Discourse codebase itself, e.g. in the Reviewables model.

I also use the pattern in a number of plugins.

The main reason the pattern is used is because the plugin_store_rows table is used by multiple plugins (and some core services), so the identifying columns, i.e. id and plugin_name, can’t be used for identification internally within each system using the PluginStore. So a string-based system is used in the key column instead.

@eviltrout

In general I recommend creating your own tables via migrations if the PluginStoreRow can’t be queried the way you want to. This is now commonly done in several plugins and works great!

In terms of changing the database structure from within a plugin, @gdpelican has a good post on this:

New columns in directory (/users)

FWIW I’ve decided to go this route with a plugin of mine, where PluginStoreRow and CustomFields didn’t qqquite cut it on their own. Caveat emptor You should be trying really hard not to do this - It’s not recommended behaviour to modify the database from within a plugin, but it can be done unobtrusively in small, additive doses (I’d say you never for any reason want to remove or change existing columns) Here’s how I did it: Write a migration in the plugin which modifies th…

Personally, I’m still quite wary of doing this as working on a third party plugin you have no control over namespacing, whether your plugin is removed and what potentially conflicting changes are made to core Discourse.

As @gdpelican mentions, you need to provide a way for your plugin user to remove the db changes if they uninstall the plugin.

Provide a method for users to clean up your database changes if they don’t want your plugin anymore. I did it with a rake task.

I feel this is too in the weeds for most plugin users and poses a risk if they’re not aware of this detail.

Moreover, I haven’t found a real need to go outside the bounds of the PluginStore and CustomFields yet.

All that said, personally I’d be in favour of a new method along these lines in PluginStore, as I find the pattern useful.

@david Would be interested in your thoughts on the above as well.