なぜzumero_syncを何度も呼び出す必要がありますか？

Question

zumero_syncのドキュメントによると：大量の情報をサーバーからプルする必要がある場合は、

この機能を複数回呼び出される必要があるかもしれません。

Zumeroを使用している私のAndroidアプリでは問題ありません。戻り値が"0;"で始まらないうちは、zumero_syncを呼び出し続けます。

しかし、今私はサーバーのdbfilesと同期する管理スクリプトを書こうとしています。私はsqlite3シェルを使い、コマンドライン引数で実行するためにSQLにスクリプトを渡してもらいたい。私はzumero_syncを呼び出す必要があります（SQLiteはサポートしていません）ので、dbが完全に同期されていることを確認してください。もし私がしなければならなかったのは、"0;"を探して、ループ内でsqlite3を呼び出したり、C++アプリケーションを使ってSQLite/Zumero関数をネイティブに呼び出すことができます。しかし、単一のzumero_syncで十分であれば確かに簡単でしょう。

私の本当の疑問は、zumero_syncが復帰する前に同期を完了するように変更できるかと思いますか？既存の動作がより有用な場合がある場合は、使用するモードを指定するパラメータがある可能性があります。

Answer 1

私はここで二つの基本的な質問を参照してください。（1）なぜzumero_sync（）はそれがないように動作しない

を？

（2）別の方法で動作しますか？

私は最初に答えるでしょう。それは簡単です：はい、それは異なった働きをするかもしれません。むしろ、zumero_sync_complete（）のような名前の関数を実装することができます（zumero_sync（）のループを実行して、同期が完了した後に戻ります）。

zumero_sync_complete（）は実装していませんでした。これはあまり価値がないためです。それは簡単なループなので、あなた自身でうまく書くことができます。 :-)

ループをサポートしていないスクリプト環境を除いて、Er。 sqlite3シェルのように。

回答（1）：それはそうしたい場合

Zumero同期プロトコルがサーバーに部分的な結果を返すように柔軟性を与えるように設計されています。そして、サーバーの負荷を軽減する（そしてそのスケーラビリティを向上させる）ために、多くの場合、はがそれをしたいと思っています。

これを考えると、これをクライアントに公開する理由の1つは、クライアントの柔軟性を高めることです。私たちは複数のラウンドトリップを行っている限り、クライアントの間に何か（例えば、進捗バーを更新するなど）をする機会を与えることもできます。

クライアントがループの繰り返しの間にやりたいことは、エラーを処理することです。

マルチスレッドクライアントの場合、同期が行われている間にクライアントで発生した変更を処理することができます。

どのようにロックを管理する必要がありますか？ループ全体でsqlite書込みロックを保持していますか？または、絶対に必要なときだけ？

ボトムライン：堅牢なアプリケーションは、ループ自体を実装して、独自の意思決定を行い、物事を完全に制御できるようにしたいと考えています。

しかし、あなたが観察したように、sqlite3シェルにはループがありません。それはアプリではありません。それにスレッドはありません。またはプログレスバー。したがって、zumero_sync（）のシンプルであまり強力でない形式が理にかなっているユースケースです。