デルタ

Question

アプリ
私はシステムのユーザーがオフラインで文書を作成する必要があるため、現在オフライン機能のためAppCacheを使用してWebアプリケーションを持っていると、クライアント - サーバのデータ同期機能を向上させます。ドキュメントは最初にオフラインで作成され、インターネットアクセスが利用可能な場合、ユーザーは「同期」をクリックしてドキュメントをサーバーに送信し、リビジョンとして保存することができます。具体的には、変更デルタをリビジョン（正確なフィールドが変更されたもの）として保存するのではなく、ドキュメント全体を保存します。つまり、「スナップショット」文書が保存されます。

問題
ユーザーは、さまざまなブラウザやデバイスからログインしてドキュメントを操作できます。 「同期」をクリックすると、サーバのドキュメントが新しい場合は、のクライアントのバージョン全体がサーバによって上書きされます。これは、下の画像に描かれている1つの主な問題につながります。

上記のシナリオは、なぜならデルタ（小さな変化）に依存しなくスナップショットのリビジョンに依存していない現在の実装が原因で発生。

いくつかの質問

1）私の研究は、私はデルタ（独立して適用することができます小さな変化）で表現する「同期」のメカニズムをアップグレードする必要があることを示します。これは健全なアプローチですか？

2）各デルタは独立して適用する必要がありますか？

2）私の研究によると、リビジョンデルタは数値であり、タイムスタンプではありません。これの価値はどういうものでしょうか？どのようにリビジョン番号を指定する必要があるのか​​、サーバーとクライアントの両方に合意するにはどうすればよいですか？

スタック情報が

• のIndexedDBは、ローカルドキュメントを保存するためのフロントエンド（オフラインモード）の角度のバックエンドでJSONBと
• PostgresのDB

Answer 1

は何あなたの記述でありますthis questionのようなバージョン管理の問題です。選択肢はあなたの解決方法です。ここでは、この問題と他の製品のいくつかの例です：

• Googleドキュメント：Aが編集オフラインになり、Bはオンライン編集を行い、Aオンラインになり、同期、Googleドキュメントは
• AとBの編集を組み合わせたAppleはノート： Googleドキュメントと同じ
は
• のGit/Subversionの：競合
• Wunderlistを解決するためにユーザーに確認し、エラーをスロー：最終編集：あなたのケースのために

以前、この最も簡単な解決策は、Wunderlistのアプローチを使用することで上書きされますが、ユーザビリティの問題を引き起こす可能性があります。あなたのユーザーは何を期待していますか？

直接あなたの質問に答える：あなたは上書きしたくない場合は

1. カスタム同期の実装が必要です。
2. これはユーザビリティの決定ですが、ユーザは何を期待していますか？
3. 実際、リビジョンは数値です（例：r1、r2）。サーバー契約を取得するには、最後の同期要求の戻り値を変更します。毎回モデル全体をクライアントに返すことができます（通常の同期が行われた場合は200 OKです）。モデルがクライアントに返された場合は、クライアントを最新のモデルに更新します。

いずれにしても、サーバーは常に真実のソースである必要があります。 This postは、サーバー/モバイル参照整合性にいくつかの良いアドバイスを提供します。

は、あなたがあなたの行の最終更新タイムスタンプを追跡する必要がある更新を追跡するために作成したタイムスタンプを...必要な挿入を追跡するには...あなたが必要と削除を追跡するために、トゥームストーンテーブル。

同期を行うときは、サーバーとモバイルデバイス間の時間オフセットを確認し、競合を解決する方法が必要であることに注意してください。挿入物は大したことではない（衝突してはならない）が、更新は競合する可能性があり、削除は更新と競合する可能性がある。