Похоже, что PluginStore — это самый простой способ реализовать сохранение идентификаторов потоков Slack для ответов в потоках, но я заметил, что единственное использование этого компонента в коде discourse-chat-integration является изолированным; фактически никто не использует полученное значение.
Означает ли это, что он устарел, или просто что задача решается другим способом?
Я планировал хранить максимум одно значение на тему, так что, учитывая всё, это кажется относительно низкой кардинальностью. Подходит ли для этого PluginStore?
Если вы храните до одного значения на тему, для этого случая может быть лучше использовать пользовательское поле темы.
PluginStore — это простое хранилище «ключ-значение», которое используется плагинами, когда кардинальность данных делает его неподходящим для существующих таблиц пользовательских полей. В последние годы мы переходим плагины на собственные таблицы для повышения надёжности данных там, где это имеет смысл, как мы сделали с плагином опросов. Вы всё ещё можете использовать его, если это подходит для вашего случая использования.
Спасибо, звучит так, что мне стоит это сделать. Так как я новичок здесь, не могли бы вы, пожалуйста, привести пример пользовательского поля темы в плагине, чтобы я мог поучиться на нём, не надоедая?
Для следующего человека, который новичок в этом и найдет это, вот некоторые ошибки, которые я совершил, будучи совершенно новым в Ruby on Rails:
Я думал, что isolate_namespace — это часть шаблона, который нужно копировать, и не понимал, что пространство имен, на которое он ссылается, относится к пространству имен маршрутов, а не к чему-либо в базе данных. Это доставило мне проблемы.
Установка пользовательского поля не сохраняет его. Вы можете сохранить объект, частью которого оно является (например, topic.save!), или просто пользовательские поля (например, topic.save_custom_fields).
Мы можем в долгосрочной перспективе отказаться как от магазина плагинов, так и от пользовательских полей, заменив их или модифицировав на гораздо более ограниченную и контролируемую систему, так как они создают больше проблем, чем приносят пользы.
Единственная область, где мы используем пользовательские поля и действительно нуждаемся в них сегодня, — это уведомление сериализаторов о том, что в посте есть «специальная» информация, или в исключительных случаях, когда вы украшаете 50% постов в системе, вы также можете размещать данные там.
Пользовательские поля слишком гибкие и имеют множество проблем с конкурентностью.
Лучший способ добавления богатых данных — это создание плагином необходимых и принадлежащих ему таблиц; это должно быть первым, что вы сделаете. Если вы столкнетесь с проблемами N+1 и другими сложностями, тогда обращайтесь к пользовательским полям, чтобы избежать их.
Как вы обычно создаете модели и миграции для плагинов? Используете ли вы стандартный генератор Rails и затем копируете их в папку плагина? Я создал собственный генератор моделей и миграций, который создает их с префиксом, специфичным для плагина. GitHub - spirobel/discourse at plugin_model_and_migrations · GitHub Возможно, это будет полезно и другим.
Я рекомендую ознакомиться с discourse-policy и плагином для опросов, чтобы увидеть примеры того, как мы проводим миграции. Именно этот шаблон вам следует использовать.
Изменения будут внедряться постепенно, и мы предоставим соответствующие рекомендации. Текущая система, основанная на сильной зависимости от магазина плагинов и пользовательских полей, привела к бесчисленным регулярным еженедельным проблемам.
Я изучил плагин «Опросы» и на его основе создал генератор моделей для плагинов, а также генератор миграций:
Если я правильно понял, одной из причин создания хранилища плагинов изначально была обеспокоенность тем, что если плагины будут создавать собственные таблицы, их имена могут вступить в конфликт. Созданные мной генераторы добавляют префикс с именем плагина к именам моделей и миграций. Я в основном создал эти генераторы, потому что в именах миграций необходимо указывать дату в начале, чтобы обеспечить предсказуемый порядок. Именно поэтому я не хотел создавать их вручную.
Хотя конфликты теоретически являются проблемой, они не стали главным мотивом. Основным стимулом было то, что не совсем понятно, как запускать миграции, и мы хотели максимально упростить этот процесс. Сегодня создание миграций в плагинах — дело простое: достаточно создать файл в папке миграций.
В любом случае конфликты всё ещё могут возникать при использовании пользовательских полей постов.
