Es sieht so aus, als wäre PluginStore der einfachste Weg für mich, das Speichern von Slack-Thread-IDs für threadierte Antworten umzusetzen – aber ich stelle fest, dass die einzige Verwendung davon in discourse-chat-integration isoliert ist; nichts nutzt tatsächlich den abgerufenen Wert.
Bedeutet das, dass er veraltet ist, oder wird dies nur auf eine andere Weise gehandhabt?
Ich würde pro Topic maximal einen Wert speichern, was angesichts der Umstände eine relativ niedrige Kardinalität bedeutet. Ist das für PluginStore angemessen?
Wenn Sie bis zu einen Wert pro Thema speichern, könnte ein benutzerdefiniertes Feld für Themen für diesen Anwendungsfall besser geeignet sein.
PluginStore ist ein einfacher KV-Speicher, der für Plugins verwendet wird, bei denen die Kardinalität der Daten bedeutet, dass er nicht gut zu den bestehenden Tabellen für benutzerdefinierte Felder passt. In den letzten Jahren haben wir Plugins auf eigene Tabellen verlagert, um eine bessere Datenzuverlässigkeit zu erreichen, wo dies sinnvoll ist, wie wir es beim Poll-Plugin getan haben. Sie können es weiterhin verwenden, wenn es für Ihren Anwendungsfall sinnvoll ist.
Danke, klingt, als sollte ich das tun. Da ich neu hier bin, könntest du mir vielleicht ein Beispiel für ein benutzerdefiniertes Themenfeld in einem Plugin geben, an dem ich lernen kann, ohne lästig zu sein?
Für die nächste Person, die neu darin ist und dies findet, hier einige der Fehler, die ich als jemand, der völlig neu bei Ruby on Rails war, gemacht habe:
Ich dachte, dass isolate_namespace Teil des zu kopierenden Musters sei, und erkannte nicht, dass sich der Namespace auf den Route-Namespace bezieht, nicht auf etwas in der Datenbank. Das hat mir Schwierigkeiten bereitet.
Das Setzen eines benutzerdefinierten Feldes speichert es nicht. Du kannst entweder das Objekt speichern, zu dem es gehört (z. B. topic.save!) oder nur die benutzerdefinierten Felder (z. B. topic.save_custom_fields).
Langfristig können wir sowohl den Plugin-Store als auch benutzerdefinierte Felder entfernen und durch ein deutlich restriktiveres und kontrollierteres System ersetzen oder anpassen, da sie mehr Probleme verursachen als sie zu helfen.
Der einzige Bereich, in dem wir heutzutage benutzerdefinierte Felder verwenden und sie wirklich benötigen, ist die Kennzeichnung für Serializer, dass „spezielle
Wow, würde das nicht große Teile des bestehenden Plugin-Ökosystems zerstören?
Mein Beitrag zu discourse-chat-integration (um Threads zu unterstützen, siehe Topic) basierte auf benutzerdefinierten Feldern, die ich hier empfohlen bekommen habe.
Wie erstellt ihr normalerweise Modelle und Migrationen für Plugins? Nutzt ihr den Standard-Rails-Generator und kopiert sie dann in den Plugin-Ordner? Ich habe mir einen eigenen Generator für Modelle und Migrationen gebaut, der Modelle und Migrationen mit einem pluginspezifischen Präfix erstellt: GitHub - spirobel/discourse at plugin_model_and_migrations · GitHub Vielleicht ist das auch für andere nützlich.
Ich empfehle, sich die discourse-policy und das Umfragens-Plugin als Beispiele dafür anzusehen, wie wir Migrationen durchführen. Dies ist das Muster, dem Sie folgen sollten.
Die Änderung wird schrittweise erfolgen, und wir werden Unterstützung anbieten. Das aktuelle System mit starker Abhängigkeit vom Plugin-Store und benutzerdefinierten Feldern hat zu unzähligen wöchentlichen Problemen geführt.
Ich habe mir das Umfragen-Plugin angesehen und darauf aufbauend einen Modellgenerator für Plugins sowie diesen Migrationsgenerator erstellt:
Wenn ich es richtig verstanden habe, war einer der Gründe, warum der Plugin-Store überhaupt erstellt wurde, die Sorge, dass die Namen von Tabellen, die Plugins selbst erstellen, kollidieren könnten. Die von mir erstellten Generatoren versehen die Namen von Modellen und Migrationen mit dem Namen des Plugins als Präfix. Ich habe diese Generatoren hauptsächlich erstellt, weil Migrationen diese Datumsnummer am Anfang benötigen, um eine vorhersagbare Reihenfolge zu gewährleisten. Deshalb wollte ich sie nicht manuell erstellen.
Kollisionen waren theoretisch zwar ein Problem, aber nicht der Hauptantrieb. Der eigentliche Anstoß war, dass es etwas unklar war, wie man Migrationen ausführt, und wir wollten etwas mit sehr geringem Aufwand. Heutzutage ist das Erstellen von Migrationen in Plugins trivial; man erstellt einfach eine Datei im Migration-Ordner.
Kollisionen können jedoch auch weiterhin bei benutzerdefinierten Feldern für Beiträge auftreten.
