Parece que o PluginStore seria a maneira mais fácil para eu implementar lembrar dos IDs de threads do Slack para respostas em thread — mas notei que o único uso dele em todo o discourse-chat-integration é órfão; nada realmente usa o valor que é consultado.
Isso significa que ele está obsoleto ou apenas que está sendo feito de outra maneira?
Eu estaria armazenando apenas um valor por tópico no máximo, então isso parece ter cardinalidade relativamente baixa, considerando tudo. Isso é razoável para o PluginStore?
Se você estiver armazenando até um valor por tópico, usar um campo personalizado de tópico pode ser melhor para esse caso de uso.
O PluginStore é um armazenamento simples de pares chave-valor (KV) usado por plugins quando a cardinalidade dos dados torna inadequado o uso das tabelas de campos personalizados existentes. Nos últimos anos, estamos migrando plugins para suas próprias tabelas para obter maior confiabilidade dos dados onde faz sentido, como fizemos com o plugin de enquetes. Você ainda pode usá-lo se fizer sentido para o seu caso de uso.
Obrigado, parece que devo fazer isso. Como sou novo por aqui, haveria alguma chance de você me dar um exemplo de um campo personalizado de tópico em um plugin para que eu possa aprender sem ser um incômodo?
Para a próxima pessoa que é nova nisso e encontra este conteúdo, aqui estão alguns dos erros que cometi como alguém completamente novo em Ruby on Rails:
Eu achei que o isolate_namespace fazia parte do padrão a ser seguido e não percebi que o namespace ao qual ele se refere é o namespace da rota, e não algo no banco de dados. Isso me causou problemas.
Definir o campo personalizado não o salva. Você pode salvar o objeto ao qual ele pertence (por exemplo, topic.save!) ou apenas os campos personalizados (por exemplo, topic.save_custom_fields)
Podemos ver a remoção tanto da loja de plugins quanto dos campos personalizados a longo prazo, substituindo-os ou ajustando-os com um sistema muito mais restrito e controlado, pois eles causam mais problemas do que ajudam.
O único lugar onde usamos campos personalizados e realmente precisamos deles hoje em dia é para sinalizar aos serializadores que existem informações “especiais” em um post ou, em casos excepcionais, quando você está decorando 50% dos posts do sistema, também colocaria dados lá.
Os campos personalizados são flexíveis demais e têm muitos problemas de concorrência.
A melhor maneira de adicionar dados ricos é fazer com que um plugin crie e gerencie as tabelas de que precisa; isso deve ser a primeira coisa que você faz. Se você ficar travado por causa de problemas como N+1 e outros, recorra aos campos personalizados para ajudar a evitá-los.
Uau, isso não quebraria grande parte do ecossistema de plugins existente?
Minha contribuição para o discourse-chat-integration (para suportar threads, veja o tópico) usou campos personalizados com base no conselho que recebi aqui.
Como você geralmente cria modelos e migrações para plugins? Você usa o gerador principal do Rails e os copia para a pasta do plugin? Eu criei meu próprio gerador de modelos e migrações, que cria modelos e migrações com um prefixo específico do plugin. GitHub - spirobel/discourse at plugin_model_and_migrations · GitHub Talvez isso seja útil para outros também.
Recomendo verificar o discourse-policy e o plugin de enquetes para alguns exemplos de como realizamos migrações. Esse é o padrão que você deve seguir.
A mudança ocorrerá ao longo do tempo e ofereceremos orientações. O sistema atual, com forte dependência da loja de plugins e campos personalizados, tem causado inúmeros problemas semanais recorrentes.
Olhei para o plugin de enquetes e, com base nele, criei um gerador de modelo para plugins e também este gerador de migrações:
Se entendi corretamente, uma das razões pelas quais a loja de plugins foi criada inicialmente foi a preocupação de que, se os plugins criassem suas próprias tabelas, os nomes poderiam entrar em conflito. Os geradores que criei prefixam os nomes dos modelos e das migrações com o nome do plugin. Criei principalmente esses geradores porque as migrações precisam ter esse número de data no início para criar uma ordem previsível. É por isso que não quis criá-las manualmente.
Embora a colisão seja teoricamente um problema, não foi a principal motivação. A grande motivação era que não estava muito claro como executar migrações e queríamos algo com o mínimo de atrito possível. Hoje em dia, criar migrações em plugins é trivial; basta criar um arquivo na pasta de migração.
De qualquer forma, colisões ainda podem ocorrer com campos personalizados de postagens.
