バージョンの主な目的は、楽観的ロックです。
有効にすると、ドキュメントが更新されるたびにバージョン値がアトミックにインクリメントされます。
これにより、アプリケーションコードは、フェッチ（たとえばバージョンキー42の取り込み）とその結果の更新（バージョン値が42のままであることを確認）の間に変更が加えられたかどうかをテストできます。バージョンキーの値が異なる場合（たとえば、ドキュメントが更新されました）、アプリケーションコードで同時変更を処理できます。
非常に同じ概念が、恐ろしいパフォーマンスをもたらす可能性のある悲観的なロックの代わりに、リレーショナルデータベースでよく使用されます。すべてのまともなORMはそのような機能を提供します。たとえば、ObjectDBのドキュメントで 。これはJavaで実装されたオブジェクトデータベースですが、同じ概念が適用されます。
ブログ投稿 Behlülのコメントにリンクされているのは、具体的な例で楽観的ロックの有用性を示していますが、配列の変更についてのみです。以下を参照してください。
反対に、これは役に立たない単純なケースです。所有者が自分で編集できるユーザープロファイルです。ここでは、楽観的ロックを取り除き、最後の編集が常に優先されると想定できます。
したがって、アプリケーションが楽観的ロックを必要とするかどうかを知っているのはあなただけです。ユースケースごと。
マングースの状況はやや特殊です。
内部ストレージ形式は位置インデックスを使用するため、オプティミスティックロックはアレイに対してのみ有効になります。これは、ブログ投稿
で説明されている問題です。 質問のコメントにリンクされています。 説明
を見つけました mongoose-ormで指定 メーリングリストは非常に明確です。他のフィールドに対して楽観的ロックが必要な場合は、自分で処理する必要があります。
これがaddの再試行戦略を実装する方法を示します 手術。繰り返しになりますが、どのように処理するかはユースケースによって異なりますが、開始するには十分なはずです。
これで問題が解決することを願っています。
乾杯