Така че, както отбелязвате, по подразбиране в mongoose е, че когато „вградите“ данни в масив като този, получавате _id стойност за всеки запис в масива като част от неговите собствени свойства на поддокумента. Всъщност можете да използвате тази стойност, за да определите индекса на елемента, който възнамерявате да актуализирате. Начинът на MongoDB за това е позиционният $ операторна променлива, която държи "съвпадащата" позиция в масива:
Folder.findOneAndUpdate(
{ "_id": folderId, "permissions._id": permission._id },
{
"$set": {
"permissions.$": permission
}
},
function(err,doc) {
}
);
Това .findOneAndUpdate() метод ще върне модифицирания документ или в противен случай можете просто да използвате .update() като метод, ако не се нуждаете от връщане на документа. Основните части са "съпоставяне" на елемента от масива за актуализиране и "идентифициране", които съвпадат с позиционния $ както бе споменато по-рано.
Тогава, разбира се, използвате $set оператор, така че само елементите, които посочите, всъщност се изпращат "по проводника" към сървъра. Можете да продължите с това с „точкова нотация“ и просто да посочите елементите, които всъщност искате да актуализирате. Като в:
Folder.findOneAndUpdate(
{ "_id": folderId, "permissions._id": permission._id },
{
"$set": {
"permissions.$.role": permission.role
}
},
function(err,doc) {
}
);
Така че това е гъвкавостта, която MongoDB предоставя, където можете да бъдете много „насочени“ в това как всъщност актуализирате документ.
Това, което прави обаче, е „заобикаляне“ на всяка логика, която може да сте вградили във вашата „мангустова“ схема, като например „валидиране“ или други „кукички за предварително записване“. Това е така, защото "оптималният" начин е "характеристика" на MongoDB и как е проектирана. Самият Mongoose се опитва да бъде "удобна" обвивка на тази логика. Но ако сте готови сами да поемете контрола, тогава актуализациите могат да бъдат направени по най-оптималния начин.
Така че, където е възможно да направите това, пазете данните си „вградени“ и не използвайте референтни модели. Позволява атомарната актуализация както на "родителски", така и на "детски" елементи в прости актуализации, където не е нужно да се притеснявате за едновременност. Вероятно е една от причините да сте избрали MongoDB на първо място.
