Adicionando um método `get_like` à classe PluginStore

[angus (Angus McLeod)]

@fzngagan

Se um plugin tiver duas ou mais entidades que deseja armazenar, digamos maçãs e laranjas, ele armazenará os dados como apple_1, apple_2… e orange_1, orange_2 de um plugin chamado fruits.

O padrão é usar o campo key na tabela plugin_store_rows para armazenar tanto um namespace quanto um identificador único, ou seja:

<namespace>_<id>

Esse padrão é menos comum nos plugins principais do Discourse atualmente, com um declínio geral no uso do PluginStore, por exemplo:

• O plugin OAuth2 Basic o usava para armazenar dados de contas associadas até que migrássemos para user_associated_accounts.

• O plugin Poll o usava antes da migração para sua própria tabela.

No entanto, ele ainda é utilizado em alguns lugares, incluindo o próprio código-base principal do Discourse, por exemplo, no modelo Reviewables.

Eu também uso esse padrão em vários plugins.

A principal razão para o uso desse padrão é que a tabela plugin_store_rows é utilizada por múltiplos plugins (e alguns serviços principais), portanto, as colunas de identificação, ou seja, id e plugin_name, não podem ser usadas para identificação interna dentro de cada sistema que utiliza o PluginStore. Assim, um sistema baseado em strings é usado na coluna key.

@eviltrout

Em geral, recomendo criar suas próprias tabelas via migrações se a PluginStoreRow não puder ser consultada da maneira que você deseja. Isso é feito comumente em vários plugins atualmente e funciona muito bem!

Em relação à alteração da estrutura do banco de dados a partir de um plugin, @gdpelican tem um bom post sobre isso:

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…

Pessoalmente, ainda estou bastante cauteloso em fazer isso, pois ao trabalhar em um plugin de terceiros, você não tem controle sobre o namespace, se seu plugin será removido e quais alterações potencialmente conflitantes podem ser feitas no Discourse principal.

Como @gdpelican menciona, você precisa fornecer uma maneira para o usuário do plugin remover as alterações no banco de dados se ele desinstalar o plugin.

Forneça um método para os usuários limparem as alterações no seu banco de dados caso não queiram mais o seu plugin. Eu fiz isso com uma tarefa rake.

Acho que isso é muito técnico para a maioria dos usuários de plugins e representa um risco se eles não estiverem cientes desse detalhe.

Além disso, ainda não encontrei uma necessidade real de sair dos limites do PluginStore e CustomFields.

Dito tudo isso, pessoalmente, eu estaria a favor de um novo método nesse sentido no PluginStore, pois acho o padrão útil.

@david, estaria interessado em ouvir sua opinião sobre o acima também.