# Adding a method \`get\_like\` to PluginStore class
**URL:** https://meta.discourse.org/t/adding-a-method-get-like-to-pluginstore-class/125026
**Category:** Development
**Created:** [August 6, 2019, 6:12pm UTC](https://meta.discourse.org/t/adding-a-method-get-like-to-pluginstore-class/125026 "2019-08-06T18:12:26Z")
**Posts on this page:** 1
**Showing post:** 6
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [August 7, 2019, 11:51pm UTC](https://meta.discourse.org/t/adding-a-method-get-like-to-pluginstore-class/125026/6 "2019-08-07T23:51:57Z")
> [@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.:
```plaintext
_
```
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](https://github.com/discourse/discourse-oauth2-basic/commit/5ae9f35e814cdc160dcd4ad77d613a70c76a5228#diff-b61ae67bc6a57a3decb8d15b832077f4L167) until we migrated it to user\_associated\_accounts.
- Poll plugin [used it prior to the migration to it’s own table](https://github.com/discourse/discourse/blob/master/plugins/poll/lib/tasks/migrate_old_polls.rake#L32).
However it is still used in places, including the core Discourse codebase itself, e.g. [in the Reviewables model](https://github.com/discourse/discourse/blob/master/app/models/reviewable.rb#L187).
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)](https://meta.discourse.org/t/new-columns-in-directory-users/77814/5):
>
> 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. warning Caveat emptor warning 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.
---
_[View the full topic](https://meta.discourse.org/t/adding-a-method-get-like-to-pluginstore-class/125026)._