Questo significa che è deprecato o semplicemente che viene gestito in un altro modo?
Sto pensando di memorizzare al massimo un valore per argomento, quindi, considerato tutto, sembra avere una cardinalità relativamente bassa. È ragionevole utilizzare PluginStore per questo scopo?
Se stai memorizzando fino a un solo valore per argomento, potrebbe essere più appropriato utilizzare un campo personalizzato dell’argomento per questo caso d’uso.
PluginStore è un semplice archivio chiave-valore (KV) utilizzato dai plugin quando la cardinalità dei dati rende inadeguate le tabelle dei campi personalizzati esistenti. Negli ultimi anni, stiamo spostando i plugin verso tabelle dedicate per ottenere una maggiore affidabilità dei dati dove ha senso, come abbiamo fatto con il plugin dei sondaggi. Puoi comunque utilizzarlo se è adatto al tuo caso d’uso.
Grazie, sembra che dovrei farlo. Dato che sono nuovo qui, c’è la possibilità che tu possa darmi un esempio di campo personalizzato per i topic in un plugin, così da poter imparare senza essere un peso?
Per la prossima persona che è nuova a questo e lo trova, ecco alcuni degli errori che ho commesso essendo completamente nuovo a Ruby on Rails:
Pensavo che isolate_namespace facesse parte del pattern da seguire, e non mi sono reso conto che lo namespace a cui si riferisce è quello delle rotte, non di nulla nel database. Questo mi ha creato problemi.
Impostare il campo personalizzato non lo salva. Puoi salvare l’oggetto a cui appartiene (ad esempio topic.save!) oppure solo i campi personalizzati (ad esempio topic.save_custom_fields)
Possiamo vedere che a lungo termine rimuoveremo sia lo store dei plugin che i campi personalizzati, sostituendoli o modificandoli con un sistema molto più restrittivo e controllato, poiché causano più problemi di quanti ne risolvano.
L’unico ambito in cui utilizziamo i campi personalizzati e ne abbiamo davvero bisogno oggi è per segnalare ai serializzatori che esistono informazioni “speciali” su un post, o in casi eccezionali quando si decorano il 50% dei post nel sistema, in cui si inserirebbero anche dati lì.
I campi personalizzati sono troppo flessibili e presentano un’ampia gamma di problemi di concorrenza.
Il modo migliore per aggiungere dati ricchi è far sì che un plugin crei e gestisca le tabelle di cui ha bisogno; questa dovrebbe essere la prima cosa da fare. Se ti trovi in difficoltà a causa di problemi N+1 o simili, allora ricorri ai campi personalizzati per evitarli.
Wow, non romperebbe gran parte dell’ecosistema esistente dei plugin?
Il mio contributo a discourse-chat-integration (per supportare i thread, vedi argomento) ha utilizzato campi personalizzati seguendo i consigli ricevuti qui.
Come create solitamente modelli e migrazioni per i plugin? Usate il generatore principale di Rails e li copiate nella cartella del plugin? Ho creato io stesso un generatore di modelli e migrazioni che crea modelli e migrazioni con un prefisso specifico del plugin. GitHub - spirobel/discourse at plugin_model_and_migrations · GitHub Forse può essere utile anche per altri.
Consiglio di consultare discourse-policy e il plugin dei sondaggi per alcuni esempi su come gestiamo le migrazioni. Questo è il modello da seguire.
Il cambiamento avverrà nel tempo e forniremo indicazioni. L’attuale sistema, basato pesantemente sullo store dei plugin e sui campi personalizzati, ha portato a innumerevoli problemi ricorrenti ogni settimana.
Ho esaminato il plugin dei sondaggi e, basandomi su di esso, ho creato un generatore di modelli per i plugin, oltre a questo generatore di migrazioni:
Se ho capito correttamente, uno dei motivi per cui è stato creato lo store dei plugin era la preoccupazione che, se i plugin creassero le proprie tabelle, i nomi potrebbero entrare in conflitto. I generatori che ho creato antepongono il nome del plugin ai nomi dei modelli e delle migrazioni. Ho creato principalmente questi generatori perché le migrazioni devono avere questo numero di data all’inizio per garantire un ordine prevedibile. Per questo motivo non volevo crearli manualmente.
Il conflitto, sebbene teoricamente un problema, non è stato la motivazione principale. La spinta principale è stata che non era del tutto chiaro come eseguire le migrazioni e volevamo qualcosa con il minimo attrito. Oggi creare migrazioni nei plugin è banale: basta creare un file nella cartella delle migrazioni.
In ogni caso, i conflitti possono verificarsi comunque con i campi personalizzati dei post.
