ドキュメントから：
versionKey は、Mongoose によって最初に作成されたときに各ドキュメントに設定されるプロパティです。このキー値には、ドキュメントの内部リビジョンが含まれています。このドキュメント プロパティの名前は構成可能です。デフォルトは __v です。これがアプリケーションと競合する場合は、次のように構成できます。
[...]
versionKey を false に設定して、ドキュメントのバージョン管理を無効にすることもできます。何をしているのかわからない場合は、バージョン管理を無効にしないでください。
しかし、気になるのは、どのような場合にこの機能を無効にしても安全なのですか?
バージョン キーの目的は楽観的ロックです。
有効にすると、ドキュメントが更新されるたびに、バージョン値がアトミックにインクリメントされます。
これにより、フェッチ (バージョン キー 42 の取り込みなど) とその後の更新 (バージョン値が 42 のままであることの確認) の間に変更が加えられたかどうかをアプリケーション コードでテストできます。バージョン キーの値が異なる場合 (ドキュメントが更新されたため 43 など)、アプリケーション コードは同時変更を処理できます。
ひどいパフォーマンスをもたらす悲観的ロックの代わりに、まったく同じ概念がリレーショナル データベースでよく使用されます。適切な ORM はすべて、このような機能を提供します。たとえば、ObjectDB documentation でうまく説明されています。これは Java で実装されたオブジェクト データベースですが、同じ概念が適用されます。
Behlül のコメントにリンクされているブログ投稿は、具体的な例で楽観的ロックの有用性を示していますが、配列の変更のみです。以下を参照してください。
反対に、これが役に立たない単純なケースがあります。所有者自身が編集できるユーザー プロファイルです。ここでは、楽観的ロックを取り除き、最後の編集が常に勝つと想定できます。
したがって、アプリケーションに楽観的ロックが必要かどうかは、あなただけが知っています。ユースケースごとに。
マングースの状況はやや特殊です。
内部ストレージ形式は位置インデックスを使用するため、オプティミスティック ロックは配列に対してのみ有効です。これは、質問のコメントにリンクされているブログ投稿で説明されている問題です。メーリング リストで説明されている説明は非常に明確であることがわかりましたmongoose-orm。他のフィールドの楽観的ロックが必要な場合は、自分で処理する必要があります。
以下は、操作の再試行戦略を実装する方法を示す要点addです。繰り返しますが、それをどのように処理したいかはユースケースによって異なりますが、始めるには十分なはずです。
これで問題が解決することを願っています。
乾杯