versionKeyは、最初のマングースによる を作成し、各文書に設定されたプロパティです。このキー値には ドキュメントの内部リビジョンが含まれています。このドキュメントプロパティの名前は設定可能です。 のデフォルトは__vです。あなたのアプリケーションでこの競合した場合、あなたは よう設定することができます。
[...]
ドキュメントのバージョン管理も falseにversionKeyを設定することにより無効にすることができます。あなたが何をしているのか分からない限り、バージョン管理を無効にしないでください。
私は好奇心が強いですが、この機能を無効にすることは安全ですか？
バージョンキーの目的は楽観的なロックです。
有効にすると、ドキュメントが更新されるたびにバージョン値がアトミックにインクリメントされます。
これにより、フェッチ（たとえばバージョンキー42のインポート）とその結果の更新（バージョン値がまだ42であることを確認する）の間に変更が加えられたかどうかをアプリケーションコードでテストできます。 バージョンキーの値が異なる場合（たとえば、ドキュメントが更新されたために43など）、アプリケーションコードは同時変更を処理できます。
恐ろしいパフォーマンスをもたらす可能性のある悲観的なロックではなく、リレーショナルデータベースでよく使用される概念です。すべての降下ORMはそのような機能を提供します。例えば、それはきれいにin ObjectDB documentationと記載されています。これはJavaで実装されたオブジェクトデータベースですが、同じ概念が適用されます。
Behlülのコメントでリンクされているblog postは、具体的な例ではオプティミスティックなロックの有用性を示していますが、配列の変更については以下を参照してください。
反対に、ここでは、その所有者が独自に編集することができるユーザープロファイルである単純なケースがあります。ここでは、楽観的なロックを取り除くことができ、最後の編集が常に勝つと仮定します。
アプリケーションがオプティミスティックロックを必要としているかどうかだけを知っています。ユースケースでユースケースを使用する
マングースの状況は多少特殊です。
内部記憶形式は位置インデックスを使用するため、オプティミスティックロックはアレイに対してのみ有効です。これは、質問のコメントにリンクされているblog postで説明されている問題です。私は、mongoose-ormメーリングリストで与えられたexplanationがかなり明確であることを発見しました。他のフィールドに対して楽観的なロックが必要な場合は、自分で処理する必要があります。
add操作の再試行戦略の実装方法を示すgistがあります。繰り返しますが、どのように処理するかはユースケースによって異なりますが、開始するだけで十分です。
これが問題を解決することを希望します。
いいえお返事
'$ in'演算子を使ってサブ文書に到達する場合、バージョン管理が必要ですか？それは私の親文書へのアクセスとは異なるようには見えません。 –
もう一度、ユースケースによって異なります。 $ in演算子を使用する場合は、同時変更ウィンドウを引き締めますが、まだ開いていることを覚えておいてください。 – eskatos
@esKotos私はあなたの新しい更新された答えはあいまいであると思う。 –
このブログ記事では、サブ文書配列の要素に位置的にアクセスする場合について説明します。しかし、マングースは実際にはポジションの代わりにIDを使用します。だから私はどちらか分かりません： http://aaronheckmann.tumblr.com/post/48943525537/mongoose-v3-part-1-versioning –