各エントリがアイテム ID であるお気に入りの配列を持つユーザーを指定します。例: { _id: 112233 "user": { "favorites": [2,7,13] } }
あなたはお気に入りの配列 [2,7,13] を得たでしょう
次に、アイテムコレクションの更新を作成します (ユーザー ID が 112233 であると仮定します)。
>db.items.update({"_id": {$in:[2,7,13]}}, {$set:{"isFavorite":true}},{ multi: true })
// yeilding
> db.items.find()
{ "_id" : 1, "value" : "myVal" }
{ "_id" : 3, "value" : "myVal" }
{ "_id" : 4, "value" : "myVal" }
{ "_id" : 2, "isFavorite" : true, "value" : "myVal" }
あなたの例では、アイテムが多少ネストされていました-これが実際のものかどうかはわかりません.
あなたのアイテムレコードが
{ _id:999,item:{_id:1,value:"myValue"}}
そして、「item._id」が 1 であるアイテムを更新するつもりだった場合 (ドキュメントの必須の _id 999 ではなく)、次のようになります。
db.items.update({"item._id": {$in:[2,7,13]}}, {$set:{"item.isFavorite":true}},{ multi: true })
ただし、@WiredPrairie で指摘されているように、これは独特のドキュメント構造です。ユーザーは自分の _id をファースト クラス フィールドとして持っていると考えるかもしれません。すべてのレコードに 1 つあるのです。
アイテム コレクションにすべての人が共有するアイテムが含まれていると仮定すると、アイテムに "isFavorite" を保存することはおそらく望ましくないでしょう。これをモデル化するもう 1 つの方法は、アイテムをお気に入りにしたユーザーの ID を含む配列を各アイテムに追加することです。
何かのようなもの
>db.items.update({"_id": {$in:[2,7,13]}},{$addToSet:{"favoredByUserIds": "user1"}},{ multi: true })
// yeilding 'user1' in the favored by array
> db.items.find()
{ "_id" : 1, "value" : "myVal" }
{ "_id" : 3, "value" : "myVal" }
{ "_id" : 4, "value" : "myVal" }
{ "_id" : 2, "favoredByUserIds" : [ "user1" ], "value" : "myVal" }
$addToSet を使用すると、操作を繰り返すことができますが、「user1」は 1 回しか追加されません。