Добавление метода `get_like` в класс PluginStore

[angus (Angus McLeod)]

@fzngagan

Если плагин имеет две или более сущностей, которые он хочет хранить, скажем, яблоки и апельсины, он будет сохранять данные как apple_1, apple_2… и orange_1, orange_2 из плагина с именем fruits.

Обычно используется поле key в таблице plugin_store_rows для хранения как пространства имен, так и уникального идентификатора, например:

<namespace>_<id>

В последнее время этот паттерн реже встречается в основных плагинах Discourse, что связано с общим снижением использования PluginStore. Например:

• Плагин OAuth2 Basic использовал его для хранения связанных данных учетных записей, пока мы не мигрировали его на user_associated_accounts.

• Плагин Poll использовал его до миграции в собственную таблицу.

Однако он все еще используется в некоторых местах, включая саму основную кодовую базу Discourse, например, в модели Reviewables.

Я также использую этот паттерн в ряде плагинов.

Основная причина использования этого паттерна заключается в том, что таблица plugin_store_rows используется несколькими плагинами (а также некоторыми основными службами), поэтому идентифицирующие столбцы, то есть id и plugin_name, не могут использоваться для внутренней идентификации в каждой системе, использующей PluginStore. Вместо этого в столбце key используется строковая система.

@eviltrout

В целом я рекомендую создавать собственные таблицы через миграции, если PluginStoreRow нельзя запросить так, как вам нужно. Сейчас это часто делается в нескольких плагинах и отлично работает!

Что касается изменения структуры базы данных изнутри плагина, у @gdpelican есть хороший пост на эту тему:

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…

Лично я все еще довольно осторожен в этом вопросе, так как при работе с сторонним плагином вы не контролируете пространство имен, удаление вашего плагина и потенциально конфликтующие изменения, вносимые в основную кодовую базу Discourse.

Как упоминает @gdpelican, вам необходимо предоставить способ для пользователя плагина удалить изменения в базе данных, если он удалит плагин.

Предоставьте метод для пользователей, чтобы очистить ваши изменения в базе данных, если они больше не хотят ваш плагин. Я сделал это с помощью задачи rake.

Мне кажется, это слишком подробно для большинства пользователей плагинов и создает риск, если они не осведомлены об этой детали.

Более того, я пока не нашел реальной необходимости выходить за рамки PluginStore и CustomFields.

Тем не менее, лично я был бы за появление нового метода по этому образцу в PluginStore, так как считаю этот паттерн полезным.

@david, мне было бы интересно узнать ваше мнение по вышеизложенному.