Ajout d'une méthode `get_like` à la classe PluginStore

[angus (Angus McLeod)]

@fzngagan

Si un plugin possède deux entités ou plus qu’il souhaite stocker, disons des pommes et des oranges, il stockera les données sous forme de apple_1, apple_2… et orange_1, orange_2 depuis un plugin nommé fruits.

Le modèle consiste à utiliser le champ key dans la table plugin_store_rows pour stocker à la fois un espace de noms et un identifiant unique, c’est-à-dire :

<namespace>_<id>

Ce modèle est moins courant dans les plugins principaux de Discourse ces derniers jours, avec un déclin général de l’utilisation de PluginStore, par exemple :

• Le plugin OAuth2 Basic l’utilisait pour stocker les données de compte associées jusqu’à ce que nous le migrions vers user_associated_accounts.

• Le plugin Poll l’utilisait avant la migration vers sa propre table.

Cependant, il est toujours utilisé à certains endroits, y compris dans le code source principal de Discourse lui-même, par exemple dans le modèle Reviewables.

J’utilise également ce modèle dans plusieurs plugins.

La raison principale de l’utilisation de ce modèle est que la table plugin_store_rows est utilisée par plusieurs plugins (et certains services principaux), de sorte que les colonnes d’identification, c’est-à-dire id et plugin_name, ne peuvent pas être utilisées pour l’identification interne dans chaque système utilisant PluginStore. Un système basé sur des chaînes de caractères est donc utilisé dans la colonne key.

@eviltrout

En général, je recommande de créer vos propres tables via des migrations si PluginStoreRow ne peut pas être interrogé de la manière dont vous le souhaitez. Cela est maintenant couramment fait dans plusieurs plugins et fonctionne très bien !

En ce qui concerne la modification de la structure de la base de données depuis un plugin, @gdpelican a un excellent post à ce sujet :

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…

Personnellement, je suis encore très prudent à ce sujet car travailler sur un plugin tiers sur lequel vous n’avez aucun contrôle en matière d’espace de noms, de suppression de votre plugin et de modifications potentiellement conflictuelles apportées à Discourse principal comporte des risques.

Comme le mentionne @gdpelican, vous devez prévoir un moyen pour vos utilisateurs de plugin de supprimer les modifications de la base de données s’ils désinstallent le plugin.

Prévoyez une méthode pour que les utilisateurs nettoient vos modifications de base de données s’ils ne veulent plus de votre plugin. Je l’ai fait avec une tâche rake.

Je pense que c’est trop technique pour la plupart des utilisateurs de plugins et présente un risque s’ils ne sont pas conscients de ce détail.

De plus, je n’ai pas encore trouvé de véritable besoin de sortir des limites de PluginStore et CustomFields.

Tout cela dit, personnellement, je serais en faveur d’une nouvelle méthode dans ce sens dans PluginStore, car je trouve ce modèle utile.

@david, je serais intéressé par vos réflexions sur ce qui précède également.