0

TouchDB-iOS を使用して、cloudant CouchDB サーバーにレプリケートするローカル CouchDB ドキュメント ストアを持つ iOS アプリを作成します。このアプリを実行しているユーザーが数人いるため、TouchDB データベースのレプリカが多数存在します。

アプリを使い始めたとき、私たちは CouchDB を初めて使用しました (今でもそうです)。タイプ A のドキュメントが次のようなプロパティを持つように関係を設計しました。これは、タイプ B のドキュメントである ID のコンマ区切りリストを記述する文字列です。

したがって、Employee/Employer の例を使用すると、"1,7,8,10" という名前Employerのプロパティがあったことになります。employeeIds従業員 10 が退職すると、このリストは「1,7,8」に更新されます。

問題は、アプリの別のインスタンス、たとえば別の電話で従業員 7 がリストを終了すると、リストが「1,8,10」に更新され、複製時に競合が発生することでした。

employerIdそのため、Employeeドキュメント プロパティに を含めることをお勧めします。従業員が退職した場合、その従業員employerIdを空に設定するだけです。そのような紛争はずっと少なくなりますよね？

私が今直面している問題は、複数のアプリが存在することです。すべての CouchDB データベースを最初の設計から 2 番目の設計に移行するにはどうすればよいですか。

すべての古いアプリを廃止する必要がありますか?それとも、既存のアプリを破壊せずに競合を最小限に抑えながら、すべてのアプリを新しいデザインに移行するフェイルセーフな方法はありますか? このケースをどのように処理するのが最善ですか?

4

1 に答える 1

0

基本的に 2 つのシナリオがあります。

アプリがデータベースに対して (ビューを介して) クエリを実行するだけの場合は、単にビューを更新して、「古いスタイル」のドキュメントと「新しいスタイル」のドキュメントを同じように処理することができます。その後、ドキュメントをバックグラウンドで更新し (たとえば、_changes フィードをたどって)、最終的に古いスタイルのドキュメントのサポートを再び削除することができます。

アプリがアプリの構造を使用している場合、アプリを更新する方法もおそらくありません。それ以外の場合は、間に古いスタイルのドキュメントと新しいスタイルのドキュメントを変換するプロキシが必要です。

CouchDB with new-style docs  <-- proxy application --> apps with old-style docs

もちろん、古いスタイルのドキュメントと新しいスタイルのドキュメントの両方を処理するようにアプリを更新して、ドキュメントを徐々に移行できるようにすることもできます。

CouchDB へのアクセスを再設計する必要がある場合は、更新ハンドラーを使用して、将来の変更をより透過的にすることを検討してください。

于 2013-10-30T17:45:51.970 に答える