KiiObject の更新

Kii Cloud にアップロードされた KiiObject をクライアントから更新する際、状況に応じて様々な更新方法を選択できます。

更新の際は以下の 2 つのオプションをサポートしています。

フルアップデートまたは部分アップデート

クライアントから JSON ドキュメントを更新したとき、送信されたキーと値のペアと、サーバー上のキーと値のペアをどのように扱うかを選択できます。

フルアップデート：クライアントからのデータで更新対象のデータを完全に上書きします。クライアントのデータにないキーは、サーバー上の既存のデータから消えます。
部分アップデート：クライアントからのデータと更新対象のデータをマージしてから上書きします。クライアントのデータにないキーは、サーバー上に残り続けます。

以下の例では、更新対象のデータのうち、gender キーがクライアントからのデータに含まれません。フルアップデートでは gender が消えますが、部分アップデートでは残ります。

大きなデータの一部だけを送信して通信のパフォーマンスを向上させたい場合や、完全に上書きして更新後のデータを明確にしたい場合など、更新の状況に応じてこれらを使い分けることができます。

更新チェックは複数のクライアントからデータを更新する際に更新の衝突が発生していないことを保証する仕組みです。これにより、楽観的ロック（Optimistic lock）として知られる手法を実現できます。更新チェックを行わなずに更新することもできます。

KiiObject をクライアントにダウンロードしてから更新処理を実行するまでの間に、他のクライアントが KiiObject を書き換えた場合に、更新をエラーにするオプションを選択できます。

以下の図は更新チェックありでの更新を表します。クライアント 1 とクライアント 2 が KiiObject をダウンロード後、同時に更新します。ここでは、後から書き込んだクライアント 2 の更新がエラーになります。

エラーになった場合は、もう一度 KiiObject をダウンロードして更新をやり直す必要があります。また、サービスによっては衝突の発生をメッセージなどで通知するのが適切な場合もあります。

アプリケーションスコープやグループスコープのように、他のクライアントから書き込まれる可能性が高い Bucket で更新チェックを行うことで、上書きによる意図しない更新を防止することができます。

ユーザースコープのように、書き換えの衝突が発生しにくい Bucket では更新チェックを行わないことで、更新処理の実装をシンプルにすることができます。

Kii Cloud では、楽観的ロックの採用により、データ更新の安全性と、スケーラビリティやパフォーマンスを両立させています。ユーザー数が増えても、データ更新の排他処理が原因でパフォーマンスの低下が発生することはありません。

KiiObject の更新機能、および、楽観的ロックについての詳細は、リファレンスガイドの「KiiObject の更新」（Android、iOS、JavaScript、REST）を参照してください。
実際のモバイルアプリでの更新に関する設計ヒントとして、サンプルアプリ Kii Balance のチュートリアルに設計方法をまとめています。本格的なデータ設計を行う際には、データの一貫性の保持を参考にしてください。