我检查了 API http://mongoosejs.com/docs/populate.html并尝试了。 似乎populate
只能在外国_id
。 即使有match
选项,它只是在_id
查询条件上添加更多过滤条件。 没有办法只填充不涉及_id
字段。
在我的项目中,我们将_id
保留为 ObjectId,并将另一个字段作为自动增量编号。 例如, customers
模型将_id
作为对象,将cuid
作为增量编号。 其他集合只是引用cuid
而不是_id
。
能够定制这个会很棒吗?
是否有任何设计限制导致此功能缺失?
能够自定义它会很棒,但现在我们强制执行_id
。 我想不出一个很好的理由为什么不呢。 我将不得不进一步调查。
不仅需要在单个其他字段上填充,甚至在一组字段上进行填充的能力才能正确支持分片,这对我们来说是一个巨大的用例。
例如,我们有一个集合“students”,它可能有一个“subscription”的分片键; 当我们从我们的sections模型(包含一个学生数组)中填充学生数据时,我们对文档有订阅,但它只会根据存储在“student”中的_id查找,而不是允许我们指定它也应该映射将文件中的“作业”字段改为学生的“作业”。
由于我们在填充时会在没有分片键的情况下进行查找,因此分片变得无用,需要命中所有分片来检索数据,而不仅仅是一个。
如果我们能得到一些关于在哪里做这项工作的指导,我们愿意为开发提供资金,甚至自己做这件事。 这是我们公司(GradeCam)的主要需求。
@taxilian你在设置shardKey
模式选项吗? AFAIK 这就是该选项的用途。
我实际上还没有开始这样做,因为我一直在寻找解决这个问题的方法; 填充是否考虑到shardKey? 我的理解是 shardKey 只影响更新和插入
能够指定要“加入”的字段会很棒,例如,我希望不仅可以通过 userId(即_id)字段填充,还可以通过 userType、userGroup 等填充。
谢谢!
+1
+1 将非常有用
+1 同样在这里!
+1 喜欢这个
+1
+1
+1
能够通过添加诸如key
类的参数来选择要填充的变量会特别好:
例如,如果有帖子我想填充author
和comments
参数,但参数在填充之前持有非 ObjectId 参数(用户名和评论标题):
{
author: "user1",
comments:["comment5", "comment6"],
title:"Post1"
}
能够添加一个像“key”这样的参数来让mongo知道要查找哪个参数会很好:
Posts.find().populate([{path:"author", model:"Users", key:"username"}, {path:"comments", model:"Comments", key:"title"}])
这将填补author
参数与用户发现用户名以及填补comments
参数与意见发现自己的头衔(我知道由标题的意见是有点不切实际,但你点)。
+1
+1
+1
+1
+1
+1
+1
大同意。 我喜欢定义自定义人口方案的能力。 对于具有一个或多个作为文件路径的字段的任何模式来说,这将非常有用,允许填充从存储中读取。
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
试试这个代码: https :
实际上,有什么理由不将 Alex 的代码合并到主仓库并使其成为核心功能?
@rturk我真的很喜欢那个插件,谢谢你指出来。 @alexmingoia你的想法是什么:将你的模块合并到猫鼬核心中? 使用虚拟来处理更通用的填充(没有将实际字段持久化到数据库)的想法非常强大。
那将是理想的。 它在核心方面会好得多,因为它重载了Query.prototype.populate
和其他核心功能。
唯一阻止我创建拉取请求的是几乎没有测试覆盖率,并且缺乏文档。 我在多个场景中的生产中使用它并且它很稳定,但我认为如果有人要编写一个测试套件,它可能会暴露一些需要记录的小问题或特质。
有人愿意处理测试套件吗? 如果没有 - 我可以做到,但不要指望下个月之前会降落。
我会看一看。 无论如何,我一直想重写填充:)
如果您对代码有任何疑问,请在 IRC(freenode, amingoia
)或 gitter 上联系我。
https://github.com/whitecolor/mongoose-fill在使用其他模型的数据填充方面也做得很好
+1
+1
+1
这是必须的:)
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+3
+1
最有用的评论
@rturk我真的很喜欢那个插件,谢谢你指出来。 @alexmingoia你的想法是什么:将你的模块合并到猫鼬核心中? 使用虚拟来处理更通用的填充(没有将实际字段持久化到数据库)的想法非常强大。