一尘不染

猫鼬查找/更新子文档

node.js

我的文件 夹Folder 具有以下架构:

var permissionSchema = new Schema({
    role: { type: String },
    create_folders: { type: Boolean },
    create_contents: { type: Boolean }
});

var folderSchema = new Schema({
    name: { type: string },
    permissions: [ permissionSchema ]
});

因此,对于每个页面,我可以拥有许多权限。在CMS中,有一个面板,其中列出了所有文件夹及其权限。管理员可以编辑一个权限并保存。

我可以很容易地用其权限数组保存整个 Folder 文档,其中只修改了一个权限。但是我不想保存所有文档(实际架构中包含更多字段),所以我这样做了:

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

        _.extend(perm, permission);

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

但是问题是 烫发 总是 不确定的 !我试图以这种方式“静态地”获取许可:

var perm = data.permissions[0];

而且效果很好,所以问题在于Underscore库无法查询权限数组。因此,我想有一种更好的方法(和工作方式)来获取所提取文档的子文档。

任何想法?

PS:我解决了使用“ for”循环检查data.permission数组中的每个项目并检查data.permissions [i] . id ==
Permission.id的问题,但是我想要一个更聪明的解决方案,我知道有一个解决方案!


阅读 204

收藏
2020-07-07

共1个答案

一尘不染

因此,正如您所注意到的,猫鼬的默认设置是,当您将数据“嵌入”这样的数组中时,您将获得_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的“功能”及其设计方式。猫鼬本身试图成为这种逻辑的“便利”包装。但是,如果您准备自己进行一些控制,则可以以最佳方式进行更新。

因此,在可能的情况下,请保持数据“嵌入”并且不要使用引用的模型。它允许您在不需要担心并发性的简单更新中对“父”和“子”项进行原子更新。可能是您应该首先选择MongoDB的原因之一。

2020-07-07