Mangouste trouver/mise à jour le sous-document

Donc, comme vous le notez, la valeur par défaut dans la mangouste est que lorsque vous "intégrer" des données dans un tableau comme cela, vous obtenez un _id valeur pour chaque entrée de ce tableau dans le cadre de son propre sous-propriétés du document. Vous pouvez réellement utiliser cette valeur pour déterminer l'index de l'élément dont vous souhaitez mettre à jour. MongoDB façon de le faire est le position $ opérateur variable, qui détient les "matched" position dans le tableau:

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

    }
);

Que .findOneAndUpdate() méthode retourne le document modifié ou sinon, vous pouvez simplement utiliser .update() comme une méthode si vous n'avez pas besoin du document retourné. Les parties principales sont le "jumelage" de l'élément de la matrice de mise à jour et "identification" qui correspondent à la position $ comme mentionné plus haut.

Alors bien sûr, vous êtes à l'aide de la $set opérateur afin que seulement les éléments que vous indiquez sont effectivement envoyés "sur le fil" sur le serveur. Vous pouvez aller plus loin avec "pointillé" et il suffit de spécifier les éléments que vous voulez mettre à jour. Comme dans:

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

    }
);

Donc, c'est la souplesse que MongoDB offre, où vous pouvez être très "ciblé" dans la façon dont vous avez fait la mise à jour d'un document.

Ce que ce fait n'est cependant "bypass" toute logique, vous pourriez avoir intégré dans votre "mangouste" schéma, telles que la "validation" ou autres "pré-enregistrer les crochets". C'est parce que le "optimale" moyen est un MongoDB "fonctionnalité" et la façon dont il est conçu. Mangouste lui-même essaie d'être un "confort" de l'emballage au cours de cette logique. Mais si vous êtes prêt à prendre un certain contrôle de vous-même, alors les mises à jour peuvent être faites dans la manière la plus optimale.

Donc si possible de le faire, de garder vos données "embedded" et de ne pas utiliser les modèles référencés. Il permet la mise à jour atomique à la fois de "parent" et "enfant" éléments de simples mises à jour où vous n'avez pas besoin de vous soucier de la concurrence. Est probablement l'une des raisons pour lesquelles vous devriez avoir sélectionné MongoDB en premier lieu.

Si vous ne voulez pas de collecte sélective, de simplement intégrer la permissionSchema dans le folderSchema.

var folderSchema = new Schema({
    name: { type: string },
    permissions: [ {
        role: { type: String },
        create_folders: { type: Boolean },
        create_contents: { type: Boolean }
    } ]
});

Si vous avez besoin de séparer les collections, c'est la meilleure approche:

Vous pourriez avoir un modèle d'Autorisation:

var mongoose = require('mongoose');
var PermissionSchema = new Schema({
  role: { type: String },
  create_folders: { type: Boolean },
  create_contents: { type: Boolean }
});

module.exports = mongoose.model('Permission', PermissionSchema);

Et un Dossier modèle avec une référence à l'autorisation du document.
Vous pouvez faire référence à un autre schéma comme ceci:

var mongoose = require('mongoose');
var FolderSchema = new Schema({
  name: { type: string },
  permissions: [ { type: mongoose.Schema.Types.ObjectId, ref: 'Permission' } ]
});

module.exports = mongoose.model('Folder', FolderSchema);

Et ensuite appeler Folder.findOne().populate('permissions') demander mangouste pour renseigner le champ des autorisations.

Maintenant, ce qui suit:

savePermission: function (folderId, permission, callback) {
    Folder.findOne({ _id: folderId }).populate('permissions').exec(function (err, data) {
        var perm = _.findWhere(data.permissions, { _id: permission._id });                

        _.extend(perm, permission);

        data.markModified("permissions");
        data.save(callback);
    });
}

La perm champ ne sera pas non défini (si l'autorisation._id est en fait dans les autorisations de tableau), car elle est peuplée par Mangouste.