Añadiendo un método `get_like` a la clase PluginStore

[angus (Angus McLeod)]

@fzngagan

Si un plugin tiene dos o más entidades que desea almacenar, digamos manzanas y naranjas, guardará los datos como apple_1, apple_2… y orange_1, orange_2 desde un plugin llamado fruits.

El patrón consiste en utilizar el campo key en la tabla plugin_store_rows para almacenar tanto un espacio de nombres como un identificador único, es decir:

<namespace>_<id>

Este patrón se observa menos en los plugins principales de Discourse en la actualidad, junto con una disminución general en el uso de PluginStore, por ejemplo:

• El plugin OAuth2 Basic lo utilizaba para almacenar datos de cuentas asociadas hasta que lo migramos a user_associated_accounts.

• El plugin Poll lo utilizaba antes de la migración a su propia tabla.

Sin embargo, todavía se utiliza en algunos lugares, incluida la propia base de código principal de Discourse, por ejemplo en el modelo Reviewables.

Yo también utilizo este patrón en varios plugins.

La razón principal por la que se utiliza este patrón es porque la tabla plugin_store_rows es utilizada por múltiples plugins (y algunos servicios principales), por lo que las columnas de identificación, es decir, id y plugin_name, no pueden utilizarse para la identificación interna dentro de cada sistema que utiliza PluginStore. Por lo tanto, se utiliza un sistema basado en cadenas en la columna key.

@eviltrout

En general, recomiendo crear tus propias tablas mediante migraciones si PluginStoreRow no se puede consultar de la manera que deseas. Esto se hace comúnmente en varios plugins y funciona muy bien.

En cuanto a cambiar la estructura de la base de datos desde dentro de un plugin, @gdpelican tiene una buena publicación sobre esto:

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…

Personalmente, sigo siendo bastante cauteloso al hacer esto, ya que al trabajar en un plugin de terceros no tienes control sobre el espacio de nombres, si tu plugin se elimina o qué cambios potencialmente conflictivos se realizan en el núcleo de Discourse.

Como menciona @gdpelican, debes proporcionar una forma de que el usuario de tu plugin elimine los cambios en la base de datos si desinstala el plugin.

Proporciona un método para que los usuarios limpien los cambios en tu base de datos si ya no quieren tu plugin. Lo hice con una tarea rake.

Siento que esto es demasiado técnico para la mayoría de los usuarios de plugins y representa un riesgo si no son conscientes de este detalle.

Además, no he encontrado una necesidad real de salir de los límites de PluginStore y CustomFields.

Dicho todo esto, personalmente estaría a favor de un nuevo método en PluginStore, como el que se describe a continuación, ya que encuentro útil este patrón.

@david, estaría interesado en conocer tu opinión sobre lo anterior también.