Methode `get_like` zur Klasse PluginStore hinzufügen

[angus (Angus McLeod)]

@fzngagan

Wenn ein Plugin zwei oder mehr Entitäten speichern möchte, sagen wir Äpfel und Orangen, speichert es die Daten als apple_1, apple_2… und orange_1, orange_2 aus einem Plugin namens fruits.

Das Muster besteht darin, das Feld key in der Tabelle plugin_store_rows zu verwenden, um sowohl einen Namespace als auch eine eindeutige Kennung zu speichern, also:

<namespace>_<id>

Dieses Muster wird bei Kern-Discourse-Plugins heutzutage seltener verwendet, da die Nutzung von PluginStore allgemein abnimmt, zum Beispiel:

• Das OAuth2 Basic Plugin verwendete es, um zugehörige Kontodaten zu speichern, bis wir es auf user_associated_accounts migriert haben.

• Das Poll-Plugin verwendete es vor der Migration in seine eigene Tabelle.

Es wird jedoch immer noch an einigen Stellen verwendet, einschließlich der Discourse-Kerncodebasis selbst, z. B. im Reviewables-Modell.

Ich verwende das Muster auch in einer Reihe von Plugins.

Der Hauptgrund für die Verwendung dieses Musters ist, dass die Tabelle plugin_store_rows von mehreren Plugins (und einigen Kernservices) genutzt wird. Daher können die identifizierenden Spalten, also id und plugin_name, nicht zur internen Identifizierung innerhalb jedes Systems verwendet werden, das PluginStore nutzt. Stattdessen wird im Feld key ein string-basiertes System verwendet.

@eviltrout

Im Allgemeinen empfehle ich, eigene Tabellen über Migrationen zu erstellen, wenn die Abfrage von PluginStoreRow nicht auf die gewünschte Weise möglich ist. Dies wird heutzutage in mehreren Plugins häufig praktiziert und funktioniert hervorragend!

Hinsichtlich der Änderung der Datenbankstruktur innerhalb eines Plugins hat @gdpelican einen guten Beitrag dazu verfasst:

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…

Persönlich bin ich immer noch sehr zurückhaltend, dies zu tun, da bei einem Drittanbieter-Plugin, über das man keine Kontrolle hat, Fragen der Namensgebung, ob das Plugin entfernt wird und welche potenziell konfliktträchtigen Änderungen an Discourse-Kernfunktionen vorgenommen werden, bestehen.

Wie @gdpelican erwähnt, müssen Sie eine Möglichkeit bieten, damit Plugin-Benutzer die Datenbankänderungen entfernen können, wenn sie das Plugin deinstallieren.

Bieten Sie eine Methode an, mit der Benutzer Ihre Datenbankänderungen bereinigen können, wenn sie Ihr Plugin nicht mehr benötigen. Ich habe dies mit einem Rake-Task umgesetzt.

Ich finde, das ist für die meisten Plugin-Benutzer zu detailliert und birgt ein Risiko, wenn sie sich dieses Details nicht bewusst sind.

Darüber hinaus habe ich noch keinen echten Bedarf gefunden, über die Grenzen von PluginStore und CustomFields hinauszugehen.

Trotzdem wäre ich persönlich für eine neue Methode in dieser Richtung in PluginStore, da ich das Muster nützlich finde.

@david, ich wäre an deinen Gedanken dazu interessiert.