这里的问题实际上是关于一些不同的东西，根本不需要$lookup。但是，对于仅从“$lookup之后过滤”标题到达此处的任何人，这些都是适合您的技术：
db.test.aggregate([
{ "$match": { "id": 100 } },
{ "$lookup": {
"from": "test",
"let": { "id": "$id" },
"pipeline": [
{ "$match": {
"value": "1",
"$expr": { "$in": [ "$$id", "$contain" ] }
}}
],
"as": "childs"
}}
])
db.test.aggregate([
{ "$match": { "id": 100 } },
{ "$lookup": {
"from": "test",
"localField": "id",
"foreignField": "contain",
"as": "childs"
}},
{ "$unwind": "$childs" },
{ "$match": { "childs.value": "1" } },
{ "$group": {
"_id": "$_id",
"id": { "$first": "$id" },
"value": { "$first": "$value" },
"contain": { "$first": "$contain" },
"childs": { "$push": "$childs" }
}}
])
如果您质疑为什么不$unwind使用$filter该数组，请阅读[Aggregate$lookup匹配管道中文档的总大小超出了所有文档的最大文档大小，以了解为什么这是通常必需的并且是最佳方法。
对于MongoDB 3.6及更高版本，通常是更具表现力的“子管道”，它是您想要在所有内容完全返回数组之前“过滤”外部集合的结果的工具。
回到答案，尽管实际上描述了为什么所提问题根本不需要“不参加”。
$lookup像这样使用并不是在这里执行所需操作的最“有效”方法。但是稍后会详细介绍。
作为一个基本概念，只需$filter在结果数组上使用：
db.test.aggregate([
{ "$match": { "id": 100 } },
{ "$lookup": {
"from": "test",
"localField": "id",
"foreignField": "contain",
"as": "childs"
}},
{ "$project": {
"id": 1,
"value": 1,
"contain": 1,
"childs": {
"$filter": {
"input": "$childs",
"as": "child",
"cond": { "$eq": [ "$$child.value", "1" ] }
}
}
}}
]);
或$redact改为使用：
db.test.aggregate([
{ "$match": { "id": 100 } },
{ "$lookup": {
"from": "test",
"localField": "id",
"foreignField": "contain",
"as": "childs"
}},
{ "$redact": {
"$cond": {
"if": {
"$or": [
{ "$eq": [ "$value", "0" ] },
{ "$eq": [ "$value", "1" ] }
]
},
"then": "$$DESCEND",
"else": "$$PRUNE"
}
}}
]);
两者都得到相同的结果：
{
"_id":ObjectId("570557d4094a4514fc1291d6"),
"id":100,
"value":"0",
"contain":[ ],
"childs":[ {
"_id":ObjectId("570557d4094a4514fc1291d7"),
"id":110,
"value":"1",
"contain":[ 100 ]
},
{
"_id":ObjectId("570557d4094a4514fc1291d8"),
"id":120,
"value":"1",
"contain":[ 100 ]
}
]
}
最重要的是，$lookup它本身不能“还”查询以仅选择某些数据。因此，所有“过滤”都需要在$lookup
但是，实际上对于这种类型的“自我连接”，您最好根本不使用它$lookup，并且完全避免额外读取和“哈希合并”的开销。只需获取相关项目，即可$group：
db.test.aggregate([
{ "$match": {
"$or": [
{ "id": 100 },
{ "contain.0": 100, "value": "1" }
]
}},
{ "$group": {
"_id": {
"$cond": {
"if": { "$eq": [ "$value", "0" ] },
"then": "$id",
"else": { "$arrayElemAt": [ "$contain", 0 ] }
}
},
"value": { "$first": { "$literal": "0"} },
"childs": {
"$push": {
"$cond": {
"if": { "$ne": [ "$value", "0" ] },
"then": "$$ROOT",
"else": null
}
}
}
}},
{ "$project": {
"value": 1,
"childs": {
"$filter": {
"input": "$childs",
"as": "child",
"cond": { "$ne": [ "$$child", null ] }
}
}
}}
])
这只是有所不同，因为我故意删除了多余的字段。如果您确实要添加它们，请自己添加：
{
"_id" : 100,
"value" : "0",
"childs" : [
{
"_id" : ObjectId("570557d4094a4514fc1291d7"),
"id" : 110,
"value" : "1",
"contain" : [ 100 ]
},
{
"_id" : ObjectId("570557d4094a4514fc1291d8"),
"id" : 120,
"value" : "1",
"contain" : [ 100 ]
}
]
}
因此，这里唯一真正的问题是“过滤”null来自数组的任何结果，该数组是在当前文档正在parent处理到时创建的$push。
您在这里似乎还缺少的是，您要查找的结果根本不需要聚合或“子查询”。您已经结束或可能在其他地方找到的结构是“设计的”，因此您可以在单个查询请求中获得一个“节点”及其所有“子代”。
这意味着只有“ query”才是真正需要的，而数据收集（由于没有真正“减少”任何内容而已发生的一切）只是迭代游标结果的功能：
var result = {};
db.test.find({
"$or": [
{ "id": 100 },
{ "contain.0": 100, "value": "1" }
]
}).sort({ "contain.0": 1 }).forEach(function(doc) {
if ( doc.id == 100 ) {
result = doc;
result.childs = []
} else {
result.childs.push(doc)
}
})
printjson(result);
这做的完全一样：
{
"_id" : ObjectId("570557d4094a4514fc1291d6"),
"id" : 100,
"value" : "0",
"contain" : [ ],
"childs" : [
{
"_id" : ObjectId("570557d4094a4514fc1291d7"),
"id" : 110,
"value" : "1",
"contain" : [
100
]
},
{
"_id" : ObjectId("570557d4094a4514fc1291d8"),
"id" : 120,
"value" : "1",
"contain" : [
100
]
}
]
}
并证明您在这里真正需要做的就是发出“单个”查询以选择父项和子项。返回的数据是相同的，并且您在服务器或客户端上所做的所有工作都在“按摩”为另一种收集的格式。
这是在这种情况下您可以“思考”如何在“关系”数据库中进行操作的情况之一，而没有意识到由于数据的存储方式已“改变”，因此您不再需要使用同样的方法。
602392714
清零编程群