Strategia per la retrocompatibilità dello storage persistente

Question

Strategia per la retrocompatibilità dello storage persistente

#1 da (7 voti)
#2 da (3 voti)
#3 da (0 voti)

7

Nella mia esperienza, provare a garantire che le nuove versioni di un'applicazione mantengano la compatibilità con l'archiviazione dei dati delle versioni precedenti può spesso essere un processo doloroso.

Quello che faccio attualmente è di salvare un numero di versione per ogni 'unità' di dati (che si tratti di un file, riga / tabella del database o qualsiasi altra cosa) e assicurarsi che il numero di versione venga aggiornato ogni volta che i dati cambiano in qualche modo . Creo anche metodi per convertire da v1 a v2, v2 a v3 e così via. In questo modo, se sono in v7 e trovo un file v3, posso fare v3- > v4- > v5- > v6- > v7.

Finora questo approccio sembra funzionare bene, ma non ho dovuto farne un uso estensivo, per cui potrebbero esserci problemi imprevisti. Sono anche preoccupato che se gli oggetti che sto caricando cambino in modo significativo, dovrò mantenere le vecchie versioni delle classi o dover aggiornare tutti i miei metodi di conversione per gestire la nuova definizione di classe.

Il mio approccio è corretto? Ci sono altri / approcci migliori che potrei usare? Esistono modelli di progettazione applicabili a questo problema?

language-agnostic persistence backward-compatibility

posta vaughandroid 04.04.2012 - 12:30

fonte

3 risposte

3

che è un sistema decente che ha gonfiato il codice per l'aggiornamento dei dati

il mio consiglio è di aggiornarlo il più possibile rimanendo pigro (leggi un oggetto da una versione precedente- > lo sovrascrivi con lo stesso oggetto (aggiornato) dalla versione corrente)

ma ti troverai nei guai se stringi le invarianti dei dati o esegui semplicemente un overhoal completo in modo che una versione precedente non possa essere aggiornata

risposta data 04.04.2012 - 14:12

fonte

0

Se i tuoi oggetti sono solo possessori di dati, puoi utilizzare la libreria di Google Protobuff o qualcosa di simile. Per ogni membro della classe / oggetto esiste una proprietà che indica se il membro esiste o meno. Ad esempio, una versione di oggetti V1 ha una proprietà denominata DataForV1 e una proprietà denominata HasDataForV1. La versione V2 non utilizza più DataForV1, pertanto HasDataForV1 restituirà sempre false e la proprietà DataForV1 potrebbe contenere valori null o predefiniti.

risposta data 04.04.2012 - 14:55

fonte

Leggi altre domande sui tag language-agnostic persistence backward-compatibility

Devo usare enumerazioni o array per un'origine dati dinamica? Che parallelismo accade in un processore vettoriale?

score 7 · Accepted Answer

Lo stai facendo bene. Stai stampando i dati con la sua versione, il che significa che hai una sua interpretazione definitiva. L'unica domanda aperta è come gestire i "vecchi" dati. Le tue scelte sono essenzialmente tra l'aggiornamento dei dati in cui vive, l'adeguamento dei dati in tempo reale al codice o la gestione di più versioni dei dati da parte del codice. Da oltre 30 anni di esperienza, posso dirvi che il primo è l'unica strada sana da seguire. Mordere il proiettile e scrivere una routine di conversione per ogni passo lungo la cronologia ed eseguirli in sequenza. Se scopri che un passaggio successivo ovvia a uno precedente ( ad es. , perché aggiornare le righe in una tabella se un passaggio successivo cancella la tabella?), Resisti alla tentazione di cortocircuitare le cose a meno che non ci sia un guadagno di prestazioni ampio e dimostrabile nel processo di aggiornamento.