Come memorizzare e convalidare i dati tra le transizioni di stato?

Mi piacerebbe andare in due modi, a seconda dei dettagli esatti di implementazione.

(Mi dispiace, non ho familiarità con Django, quindi la mia risposta parla genericamente dell'architettura e non ha suggerimenti specifici per la lingua che stai usando)

1. Campi JSON per i dati che utilizzano l'ereditarietà tabella singola

Come hai suggerito, inserirò i dati nei campi JSON (B) in Postgres. Mi piacerebbe convalidare per sottoclassi (o simili) il modello Tasks usando Single Table Inheritance (STI).

Un rapido google suggerisce che Django potrebbe non fare STI in modo nativo, ma potresti ottenere una versione abbastanza semplice lavorando aggiungendo, ad esempio, una colonna type alla tabella delle attività e utilizzandola per caricare dinamicamente la classe che contiene le tue convalide per quel tipo di attività.

Pro

• Espressivo: le tue regole di convalida sono flessibili come la lingua
• Semplice - Facile da usare e usare

Contro

• Imbarazzante in scala - Se disponi di diversi tipi di attività, questo potrebbe sfuggire di mano per la manutenzione. (Questo può essere mitigato raggruppando attività simili per usare la stessa classe di validazione)
• Dipendente dallo sviluppatore: eventuali modifiche alla convalida o l'aggiunta di nuove attività richiedono uno sviluppatore

2. Conservazione della convalida anche in JSON

Avere una seconda tabella che memorizza i tipi di attività che utilizza lo schema JSON per descrivere gli attributi e la convalida di un'attività

Pro

• Strumenti standard: se utilizzi lo schema JSON, ci sarebbero delle librerie standard con le quali potresti lavorare per convalidare le attività
• Più facile da scalare: basta aggiungere un nuovo tipo di attività alla tabella del tipo di compito

Contro

• Potrebbe essere un po 'più lento - Un po' più impegnato per lo sviluppo iniziale
• Less Expressive - Lo schema JSON non è un linguaggio di programmazione, quindi non è così espressivo per la definizione delle regole (ma in pratica sarebbe sufficiente per la maggior parte dei casi)

Comprendiamo il tuo contesto:

users of the application will be able to create their own state machines, limited by little pieces of code that are pré built, lets call those tasks.

depending on the tasks involved, we will need to force user to input a certain data.

Background: Django, marionette js, Django rest Framework and PostgreSQL.

Ora, le tue domande:

How can we: Store the data we need, which will be different, depending on the fsm and the tasks it will perform? I was thinking a big json blob.

Potresti:

• Crea una tabella N x N in Postgree (o qualsiasi altro DB di relazione che stai utilizzando) specificando le relazioni tra le parti pre-create che hai citato e ciascuna FSM personalizzata; è possibile creare una tabella Field, che conterrà l'input immesso dall'utente e il campo potrebbe avere un riferimento all'attività pre-creata presente nell'FSM dell'utente;
• Per i dati della struttura ben strutturata, che difficilmente cambieranno gli straordinari (come utenti / ruoli / permessi nella tua app), continui a utilizzare il DB delle relazioni. Per i dati con struttura dinamica o nei casi in cui ciascuna istanza potrebbe avere un formato diverso, è possibile memorizzare queste informazioni in un DB non relazionale o NoSQL (ad esempio: mongoDB , che utilizza internamente il formato Bson). L'implementazione per questo sarà molto semplice e si integra perfettamente con python (ho usato pymongo per questo)

Informazioni sui commenti: Se utilizzare o meno un DB è completamente ortogonale alla domanda che l'OP ha chiesto

Esistono applicazioni che utilizzano più tipi di DB, a seconda delle funzionalità di cui ha bisogno. Esistono app che utilizzano DB relazionale (ad esempio: server SQL), DB no-sql (ad esempio: mongoDB) e anche DB in memoria (es .: Redis). Trello, ad esempio, usa mongo e redis. Poiché questo post è contrassegnato con "architettura", penso che valga la pena menzionare queste opzioni, poiché potrebbe essere utile per aiutare a risolvere il problema dell'OP.

How can we: Validate it, without going insane.

Dato che hai parti pre-costruite su questa funzione, dovresti creare validatori predefiniti per le possibili informazioni di inserimento inserite dall'utente.

Se si implementa qualche entità Field, ad esempio, con una proprietà "Type" su di essa, è possibile implementare i validatori per questo tipo di campo; quando l'utente riempie queste informazioni e sceglie il tipo "numerico", l'app attiva i validatori appropriati.

Se fornisci ulteriori dettagli sugli stati e sull'input inseriti, forse posso fornire alcuni esempi di codice.