Come gestire la migrazione dei dati in corso?

3

Lavoro in un progetto SaaS in cui ogni utente può avere una rappresentazione di alcuni dati comuni in un dato momento. Per fare un esempio, consideriamo che i dati di ciascun utente sono metadati su di essi mantenuti separatamente su disco come file JSON:

{
  "name" : "Bob"
}

Con l'arrivo di nuovi requisiti, questa rappresentazione sottostante potrebbe cambiare (ad esempio, nel JSON precedente, supponiamo che l'attributo name sia cambiato in firstName e che venga aggiunto un altro attributo lastName ). Per supportare gli artefatti creati in momenti diversi, siamo costretti a gestirli in due modi:

  1. Migrazione di tutti i dati dalla vecchia rappresentazione a nuova
  2. Segui percorsi di codice / logica condizionale diversi a seconda della rappresentazione sottostante:

.

if (oldRepresentation) {
  ... do this ... 
} else if (middleRepresentation) {
  ... do that ... 
} else {
  ... do something else ... 
}

Entrambi sembrano problematici in quanto è un approccio big bang (e sappiamo tutti che le migrazioni sono raramente lisce) e l'altro crea una certa dose di dissonanza nella sorgente con tutta la logica condizionale. Sono curioso di sapere come altri progetti gestiscono le migrazioni di questo tipo? La maggior parte di voi usa uno degli approcci precedenti? In che modo la tua architettura tiene conto di questo? Disponi di un servizio separato per eseguire le migrazioni su richiesta?

    
posta naivedeveloper 14.07.2015 - 04:13
fonte

2 risposte

2

Il modo migliore è quello di memorizzare un numero di versione in ciascuno dei file persistenti. Quindi puoi leggerne uno qualsiasi, in qualsiasi momento e se la versione non è quella corrente, inviarlo a una routine di migrazione che lo aggiorna al formato corrente e quindi continuare ad elaborarlo come se fosse sempre il formato corrente.

Ciò consente di eseguire la migrazione in base alle necessità, piuttosto che una lunga procedura di conversione di tutti i record. Consente inoltre di conservare i record in modelli offline o scollegati. Il tuo codebase è molto più semplice in quanto deve gestire solo il formato corrente, anche se dovrai aggiungere continuamente le regole a una routine di migrazione mentre aggiungi nuovi formati.

Per far funzionare tutto questo, DEVI memorizzare una versione. Cercando di indovinare che il formato del file è dopo 2 o 3 revisioni del formato non sarà divertente. Se attualmente non memorizzi il numero di versione, va bene - tutti i file senza uno sono semplicemente v0 di default. La migrazione dovrebbe aggiungerne uno.

    
risposta data 14.07.2015 - 14:43
fonte
0

La conversione dei file di dati dai "vecchi" formati al più recente e più grande è probabilmente l'opzione migliore. Salvare i dati riformattati dopo la conversione. In questo modo, i dati verranno aggiornati gradualmente, nel tempo, anziché in un "Big Bang". Ogni volta che si accede a un file, esso viene aggiornato alla versione più recente (qualunque sia oggi ) e nessuno è più saggio. È un po 'come il Database Oracle; controlla solo la corruzione del blocco mentre legge un blocco dal disco.

Un possibile problema è se devi eseguire il back-out di una versione dell'applicazione. Devi quindi essere in grado di "downgrade" i tuoi file alla versione precedente, che potrebbe essere una sorta di sfida.

    
risposta data 14.07.2015 - 14:34
fonte

Leggi altre domande sui tag