はじめに
ドキュメントの構造
Couchbase Liteのデータ単位はドキュメントであり、これはRDBの行またはレコードに相当します。
ドキュメントは、一意で不変のキー、Id、およびユーザーのデータを表す値（JSONオブジェクトまたはバイナリブロブ）で構成されるキーと値のペアとして保存されます。
キー
ドキュメントキー/IDの特徴は次のとおりです。
- スペースを含まないUTF-8文字列(％、/、 "、_などの特殊文字を許容)
- 250バイト以下
- バケット内でユニーク
- （UUIDとして）自動的に生成されるか、保存時にユーザーまたはアプリケーションによって設定されます
- 不変; つまり、一度保存するとIDを変更できません。
値
ドキュメントの値は次のいずれかです。
ドキュメントと呼ばれるJSON値。
このJSONオブジェクトは、それ自体がキーと値のペアのコレクションであり、値は数値、文字列、配列、またはネストされたオブジェクト自体である可能性があります。その結果、ドキュメントは、非常に複雑なデータ構造を、簡単に解析可能で自己組織化された方法で表すことができます。
バイナリオブジェクト（blobまたは添付ファイルとも呼ばれます）
これらの添付ファイルは、大きなメディアファイルやその他の非テキストデータを保存する手段を提供します。Couchbase Liteは無制限のサイズの添付ファイルをサポートしていますが、Sync Gatewayは現在、同期される添付ファイルに20MBの制限を課しています。
ドキュメント属性
各ドキュメントには次の属性があります。
- ドキュメントID
- 現在のリビジョンID（ドキュメントが更新されるたびに変更されます）
- 過去のリビジョンIDの履歴（通常は線形ですが、ドキュメントに競合がある場合、または競合した場合は分岐ツリーを形成します）
- JSONオブジェクトの形式の本文、つまりキーと値のペアのセット
- 0個以上の名前付きバイナリ添付ファイル
ドキュメントの変更履歴
Couchbase Liteは、GitやSubversionなどのバージョン管理システムのように、すべてのドキュメントの変更履歴を一連のリビジョンとして追跡します。その主な目的は、レプリケーターが同期するデータと発生する競合を判別できるようにすることです。
ドキュメントの変更ごとに、一意のリビジョンIDが割り当てられます。過去のリビジョンのIDが利用可能です。リビジョンがローカルで作成され、データベースがまだ圧縮されていない場合、過去のリビジョンのコンテンツが利用できる場合があります。
ドキュメントの制約
概要
ここに記載されている制約は、Sync Gatewayを使用して複製する必要がある、または必要になる可能性のあるデータバケットとドキュメントの設計に関連しています。
避けるべきこと
アンダースコア文字「_」（ASCII _）を前に付けたユーザープロパティ名の設計は避ける。
なぜそれが問題なのか
アンダースコア文字は、（「_」）で予約された接頭辞のためのドキュメント（文書の識別子：例えば、システムプロパティ_id（）とリビジョン属性_rev）。
先頭にアンダースコアが付いたユーザープロパティを含むドキュメントは、Sync Gatewayによって拒否されます。エラーの詳細については、例1を参照してください。
プロパティプレフィックスエラーメッセージの例
"{"error":"Bad Request","reason":"user defined top level properties beginning with '_' are not allowed in document body"}"
適用される場所
このルールは、次の方法で実行される書き込みに適用されます。
- Couchbase Lite SDK
- Sync Gateway REST APIの同期
- 共有バケットアクセスが有効になっている場合のCouchbase Server SDK
エラーが発生する可能性があるケース
特に、次の展開状況でエラーが発生する可能性があります。
-
フィールドレベルの暗号化が有効になっているモバイルからWebへのデータ同期(ルールがデフォルトのフィールド暗号化形式と競合するため)
-
Node.js SDKとOttoman.js（Couchbase用のNode.js ODM）を使用したモバイルからWebへのデータ同期（はOttoman.jsによって自動的に追加されるプロパティ
_typeと競合するため）。 -
このシナリオで推奨される回避策は、Ottoman.jsライブラリをフォークし、
_typeプロパティの検索置換を実行して、先頭にアンダースコアを付けずに置換することです。
参考情報