Il semble que PluginStore soit le moyen le plus simple pour moi d’implémenter le stockage des IDs de threads Slack pour les réponses en thread — mais je remarque que la seule utilisation de celui-ci dans tout discourse-chat-integration est orpheline ; rien n’utilise réellement la valeur récupérée.
Cela signifie-t-il qu’il est déprécié ou simplement qu’une autre méthode est utilisée ?
Je ne stockerais qu’une seule valeur par sujet au maximum, donc cela semble avoir une cardinalité relativement faible, toutes choses considérées. Est-ce raisonnable pour PluginStore ?
Si vous stockez jusqu’à une seule valeur par sujet, l’utilisation d’un champ personnalisé de sujet pourrait être plus adaptée à ce cas d’usage.
PluginStore est un simple magasin clé-valeur utilisé par les plugins lorsque la cardinalité des données rend les tables de champs personnalisés existantes inadaptées. Ces dernières années, nous déplaçons les plugins vers leurs propres tables pour améliorer la fiabilité des données lorsque cela a du sens, comme nous l’avons fait avec le plugin de sondage. Vous pouvez toujours l’utiliser si cela correspond à votre cas d’usage.
Merci, ça a l’air d’être la bonne approche. Comme je suis nouveau ici, auriez-vous la gentillesse de me donner un exemple de champ personnalisé pour un sujet dans un plugin, afin que je puisse apprendre sans être importun ?
Pour la prochaine personne qui découvre cela et tombe sur ce message, voici quelques erreurs que j’ai commises en tant que débutant complet avec Ruby on Rails :
J’ai cru que isolate_namespace faisait partie du modèle à suivre, sans réaliser que l’espace de noms auquel il se réfère est l’espace de noms des routes, et non celui de la base de données. Cela m’a causé des problèmes.
Définir un champ personnalisé ne le sauvegarde pas. Vous pouvez sauvegarder l’objet auquel il appartient (par exemple topic.save!) ou simplement les champs personnalisés (par exemple topic.save_custom_fields).
À long terme, nous envisageons de supprimer à la fois la boutique de plugins et les champs personnalisés, pour les remplacer ou les modifier par un système beaucoup plus restreint et contrôlé, car ils causent plus de problèmes qu’ils n’aident réellement.
L’unique cas où nous utilisons encore les champs personnalisés et où ils sont vraiment nécessaires aujourd’hui, c’est pour signaler aux sérialiseurs qu’il existe des informations « spéciales » sur un article, ou dans des cas exceptionnels où vous personnalisez 50 % des articles du système, auquel cas vous stockeriez également les données là-bas.
Les champs personnalisés sont trop flexibles et posent de nombreux problèmes de concurrence.
La meilleure approche pour ajouter des données riches consiste à ce qu’un plugin crée et gère ses propres tables. C’est la première chose à faire. Si vous rencontrez des problèmes comme le problème N+1 ou d’autres difficultés, vous pourrez alors recourir aux champs personnalisés pour les éviter.
Wow, cela ne casserait-il pas de larges pans de l’écosystème existant des plugins ?
Ma contribution à discourse-chat-integration (pour prendre en charge les fils de discussion, voir le sujet) utilisait des champs personnalisés, conformément aux conseils que j’ai reçus ici.
Comment créez-vous habituellement les modèles et les migrations pour les plugins ? Utilisez-vous le générateur principal de Rails et les copiez-vous dans le dossier du plugin ? J’ai créé moi-même un générateur de modèles et de migrations qui ajoute un préfixe spécifique au plugin aux modèles et migrations générés. GitHub - spirobel/discourse at plugin_model_and_migrations · GitHub Peut-être que cela pourra aussi être utile à d’autres.
Je recommande de consulter le discourse-policy et le plugin des sondages pour quelques exemples sur la façon dont nous effectuons les migrations. C’est le modèle que vous devez suivre.
Le changement se fera progressivement et nous fournirons des orientations. Le système actuel, qui repose fortement sur le magasin de plugins et les champs personnalisés, a conduit à d’innombrables problèmes réguliers chaque semaine.
J’ai examiné le plugin des sondages et, sur cette base, j’ai créé un générateur de modèles pour les plugins ainsi que ce générateur de migrations :
Si j’ai bien compris, l’une des raisons pour lesquelles le pluginstore a été créé à l’origine était la crainte que, si les plugins créaient leurs propres tables, les noms puissent entrer en collision. Les générateurs que j’ai créés préfixeront les noms des modèles et des migrations avec le nom du plugin. J’ai principalement créé ces générateurs car les migrations doivent comporter ce numéro de date devant pour établir un ordre prévisible. C’est pourquoi je ne voulais pas les créer manuellement.
Le conflit, bien que théoriquement problématique, n’était pas une motivation majeure. La principale motivation était qu’il n’était pas tout à fait clair comment exécuter les migrations, et nous souhaitions quelque chose de très simple à mettre en œuvre. De nos jours, créer des migrations dans les plugins est trivial : il suffit de créer un fichier dans le dossier de migrations.
Les conflits peuvent néanmoins toujours se produire avec les champs personnalisés des publications.
