Mongoose find/update subdocument

So as you note, the default in mongoose is that when you “embed” data in an array like this you get an _id value for each array entry as part of it’s own sub-document properties. You can actually use this value in order to determine the index of the item which you intend to update. The MongoDB way of doing this is the positional $ operator variable, which holds the “matched” position in the array:

Folder.findOneAndUpdate(
    { "_id": folderId, "permissions._id": permission._id },
    { 
        "$set": {
            "permissions.$": permission
        }
    },
    function(err,doc) {

    }
);

That .findOneAndUpdate() method will return the modified document or otherwise you can just use .update() as a method if you don’t need the document returned. The main parts are “matching” the element of the array to update and “identifying” that match with the positional $ as mentioned earlier.

Then of course you are using the $set operator so that only the elements you specify are actually sent “over the wire” to the server. You can take this further with “dot notation” and just specify the elements you actually want to update. As in:

Folder.findOneAndUpdate(
    { "_id": folderId, "permissions._id": permission._id },
    { 
        "$set": {
            "permissions.$.role": permission.role
        }
    },
    function(err,doc) {

    }
);

So this is the flexibility that MongoDB provides, where you can be very “targeted” in how you actually update a document.

What this does do however is “bypass” any logic you might have built into your “mongoose” schema, such as “validation” or other “pre-save hooks”. That is because the “optimal” way is a MongoDB “feature” and how it is designed. Mongoose itself tries to be a “convenience” wrapper over this logic. But if you are prepared to take some control yourself, then the updates can be made in the most optimal way.

So where possible to do so, keep your data “embedded” and don’t use referenced models. It allows the atomic update of both “parent” and “child” items in simple updates where you don’t need to worry about concurrency. Probably is one of the reasons you should have selected MongoDB in the first place.