Aggiunta del metodo `get_like` alla classe PluginStore

[angus (Angus McLeod)]

@fzngagan

Se un plugin ha due o più entità che desidera memorizzare, ad esempio mele e arance, conserverà i dati come apple_1, apple_2… e orange_1, orange_2 da un plugin chiamato fruits.

Il modello prevede l’uso del campo key nella tabella plugin_store_rows per memorizzare sia uno spazio dei nomi sia un identificatore univoco, ovvero:

<namespace>_<id>

Questo modello è meno frequente nei plugin core di Discourse oggi, con un calo generale nell’uso di PluginStore, ad esempio:

• Il plugin OAuth2 Basic lo ha utilizzato per memorizzare i dati associati all’account fino alla migrazione verso user_associated_accounts.

• Il plugin Poll lo ha utilizzato prima della migrazione verso la propria tabella.

Tuttavia, viene ancora utilizzato in alcuni contesti, inclusa la codebase core di Discourse stessa, ad esempio nel modello Reviewables.

Anch’io utilizzo questo modello in numerosi plugin.

Il motivo principale per cui si usa questo modello è che la tabella plugin_store_rows è utilizzata da più plugin (e da alcuni servizi core), quindi le colonne identificative, ovvero id e plugin_name, non possono essere impiegate per l’identificazione interna all’interno di ciascun sistema che utilizza PluginStore. Di conseguenza, nel campo key viene adottato un sistema basato su stringhe.

@eviltrout

In generale, consiglio di creare le proprie tabelle tramite migrazioni se PluginStoreRow non può essere interrogato nel modo desiderato. Questa pratica è ormai comune in diversi plugin e funziona benissimo!

Per quanto riguarda la modifica della struttura del database all’interno di un plugin, @gdpelican ha un ottimo post a riguardo:

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, sono ancora molto cauto nel farlo, poiché lavorando su un plugin di terze parti non hai il controllo sul namespace, sulla rimozione del tuo plugin o su eventuali modifiche conflittuali apportate al core di Discourse.

Come menziona @gdpelican, devi fornire un modo per gli utenti del plugin per rimuovere le modifiche al database se disinstallano il plugin.

Fornisci un metodo per gli utenti per pulire le modifiche al database se non vogliono più il tuo plugin. L’ho fatto con un task rake.

Ritengo che questo sia troppo tecnico per la maggior parte degli utenti dei plugin e rappresenti un rischio se non sono a conoscenza di questo dettaglio.

Inoltre, non ho ancora riscontrato un reale bisogno di uscire dai limiti di PluginStore e CustomFields.

Detto questo, personalmente sarei favorevole all’introduzione di un nuovo metodo in PluginStore, in quanto trovo utile questo modello.

@david Sarei interessato anche alle tue riflessioni su quanto sopra.