Perché zumero_sync deve essere chiamato più volte?

Question

Secondo la documentazione per zumero_sync:

Se una grande quantità di informazioni ha bisogno di essere tirato dal server, questa funzione può avere bisogno di essere chiamato più di una volta.

Nella mia app per Android che utilizza Zumero non c'è problema; Continuo a chiamare zumero_sync finché il valore restituito non inizia con "0;".

Tuttavia, ora sto cercando di scrivere uno script di amministrazione che si sincronizzi anche con il mio server dbfiles. Mi piacerebbe usare la shell sqlite3 e fare in modo che lo script passi l'SQL per eseguire gli argomenti della riga di comando. Devo chiamare zumero_sync in un ciclo (che SQLite non supporta) per assicurarmi che il db sia completamente sincronizzato. Se dovessi, potrei invocare sqlite3 in un ciclo (leggendo il suo output, cercando "0;"), o anche scrivere un'app C++ per chiamare le funzioni SQLite/Zumero in modo nativo. Ma certamente sarebbe più facile se un singolo zumero_sync fosse abbastanza.

Credo che la mia vera domanda sia: potrebbe zumero_sync essere modificato in modo che completa la sincronizzazione prima di tornare? Se ci sono casi in cui il comportamento esistente è più utile, potrebbe esserci un parametro per specificare quale modalità usare?

Answer 1

Vedo due domande fondamentali: qui

(1) Perché zumero_sync() funziona nel modo in cui funziona?

(2) Può funzionare in modo diverso?

Risponderò prima (2), poiché è più semplice: Sì, potrebbe funzionare in modo diverso. Piuttosto, potremmo (e probabilmente lo farete presto) implementare una funzione aggiuntiva, chiamata qualcosa come zumero_sync_complete(), che esegue [il coraggio di] zumero_sync() in un ciclo e ritorna dopo che la sincronizzazione è completa.

Non abbiamo implementato zumero_sync_complete() perché non aggiunge molto valore. È un ciclo semplice, quindi puoi benissimo scrivere da solo. :-)

Er, tranne che in ambienti di script che non supportano i loop. Come la shell sqlite3.

Risposta a (1):

Il protocollo di sincronizzazione Zumero è stato progettato per dare al server la possibilità di restituire i risultati parziali, se vuole farlo. E per ridurre il carico sul server (e aumentare la sua scalabilità) spesso fa fare esattamente questo.

Dato che, una ragione per esporre questo al cliente è di aumentare anche la flessibilità del cliente. Per tutto il tempo che stiamo facendo più roundtrip, potremmo anche dare al cliente l'opportunità di fare qualcosa (come, forse, aggiornare una barra di avanzamento) tra di loro.

Un'altra cosa che un client potrebbe desiderare di fare tra le iterazioni del ciclo è gestire un errore.

Oppure, nel caso di un client con multithreading, potrebbe voler gestire le modifiche avvenute sul client durante la sincronizzazione.

Il che solleva la questione di come deve essere gestito il blocco?Manteniamo il blocco di scrittura sqlite durante l'intero ciclo? O solo quando assolutamente necessario?

Bottom line: Un'app robusta vorrebbe probabilmente implementare il loop stesso in modo che possa prendere le proprie decisioni e mantenere il pieno controllo sulle cose.

Ma, come si osserva, la shell sqlite3 non ha loop. E non è un'app. E non ha discussioni. O barre di avanzamento. Quindi è un caso d'uso in cui una forma più semplice e meno potente di zumero_sync() avrebbe senso.