Scenario attuale:

DEVICE1 :

• col1
• col2
• col3

DEVICE2 :

• col1
• col2
• col4
• Col5

DEVICE3 :

• col1
• col3
• Col5

E ogni dispositivo è collegato al tuo "server", cioè c'è una copia dei dati dalla tua parte.

Sincronizzazione:

Per sincronizzare in modo significativo, il componente server deve avere un superset di tutte le colonne

server :

• col1

• col2

• col3

• col4

• Col5

Ogni dispositivo esegue una query per una rappresentazione corrente dello stato del server e aggiorna le sue colonne (ad esempio, Device2 seleziona 1,2,4,5).

Questo dovrebbe fare il trucco.

Modifica per rispondere alle domande dalla sezione dei commenti

what would be if the data type (of a column) is changed in one version?

Dipende da cosa intendi per datatype is changed ? Supponiamo che tu abbia in V1 scelto String per DOB e in tutte le altre versioni, hai un Timestamp non ci dovrebbero essere problemi: l'aggiornamento deve gestire un modulo marshalled e il processo di unmarshalling dovrebbe fare le conversioni necessarie (scrivendo una stringa nel DB o convertendo una stringa in Timestamp ).

In generale : Ci dovrebbe essere una forma canonica ("la verità") sul server e ogni applicazione dovrebbe fare la trasposizione ai loro bisogni.

Also how do we deal with the naming for the columns (for example, Person (name, age, dob)) ? Do you think I should name like Person('name_v1, age_v1, dob_v1'), Person('name_v2, height_v2, age_v2, dob_v2') etc. something like that?

Da quanto scritto sopra dovrebbe essere chiaro: non è necessario nominare speciali di differenti column_versions. Problematico: se hai qualche tipo di limiti di lunghezza: vince il più corto.

Da quanto ho letto fino ad ora, consiglierei di considerarlo solo come una soluzione temporanea e raccomandiamo vivamente di motivare (tramite denaro, funzioni, denaro e caratteristiche, qualunque) le persone ad aggiornare a una versione più recente della vostra applicazione. Tu e il tuo cliente avrete meno mal di testa.

In questi casi, devi tenere traccia degli utenti con la versione dell'app. Ogni volta che si apportano modifiche nello schema del database, se qualcuno utilizza la versione precedente, non eliminare il nome della colonna. Puoi farlo solo quando non ci sono utenti che usano quella versione.

Per gestire più versioni dell'app, è necessario lavorare di più sulle API. È possibile gestire tali casi utilizzando il numero di versione a livello di API.

Durante l'utilizzo dell'API, invia il numero di versione nell'API e dai / ottieni la risposta in base alle modifiche della versione.

L'applicazione dovrebbe essere pianificata dall'inizio per la compatibilità con le versioni precedenti, quindi qualsiasi nuova versione non rimuoverà la vecchia funzionalità (o rimuoverà le colonne dello schema DB). In questo modo garantisci che la nuova versione funzionerà sempre con il vecchio DB.

Tuttavia, se è necessario sincronizzare solo determinati dati, è possibile aggiungere un adattatore di sincronizzazione per ogni versione per unificare lo scambio di dati tra di essi senza modificare molto gli interni della versione e mantenendo le versioni DB più indipendenti e flessibili.

Utilizziamo tre livelli di numerazione della propria versione.

1. Versione del codice di frontend (con hardcoded)
2. Versione API (hardcoded)
3. Versione del database (memorizzata in una costante db)

Se non tutti sono uguali, forza qualche aggiornamento del livello deviante. La routine di controllo e aggiornamento viene avviata all'avvio.