Question

此示例聚合将引发IllegalArgumentException无效的引用＆＃39;角色＆＃39;！

在投影阶段后重命名字段后，我们每次都遇到此问题。

    final Aggregation aggregation = newAggregation(

            // We only like to have the "company" and "empolyee.role" renamed to "role"
            project("company")
                    .and("employee.role").as("role"),

            // Group by the **renamed** "role"
            group("role").count().as("count"), // this will fail because "role" is an invalid reference.
            limit(2)
            );

    return aggregation;

我们正在研究的JSON看起来像这样：

{
    // some fields
    company : {
          // some fields
    }

    employee : {
           role : {
                    // some fields
           }

    } 
}

思想：

Here奥利弗说道。

了解您根据类型属性定义聚合非常重要，而不是文档字段名称。

这就是我们获得例外的原因吗？如果是这样，如何使用漂亮的aggegration api spring数据提供。

更新：

这是我在1.5.0.M1版本中获得的Stacktrace：

java.lang.IllegalArgumentException: Invalid reference 'role'!
    at org.springframework.data.mongodb.core.aggregation.ExposedFieldsAggregationOperationContext.getReference(ExposedFieldsAggregationOperationContext.java:78)
    at org.springframework.data.mongodb.core.aggregation.ExposedFieldsAggregationOperationContext.getReference(ExposedFieldsAggregationOperationContext.java:62)
    at org.springframework.data.mongodb.core.aggregation.GroupOperation.toDBObject(GroupOperation.java:292)
    at org.springframework.data.mongodb.core.aggregation.Aggregation.toDbObject(Aggregation.java:247)
    at com.xxx.report.adapter.AggrigateByTopic.aggrigateBy(AggrigateByTopic.java:38)
    at com.xxx.report.adapter.AggrigateByTopicTest.shouldAggrigate(AggrigateByTopicTest.java:38)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
    at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:83)
    at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
    at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:232)
    at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:89)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
    at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:175)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Answer 1

确实，实施＆＃34;不喜欢＆＃34;你在这里做的字段别名的类型，但在最严格的解释中，你正在做的事情没有多大意义。

你的陈述应该是这样的：

    final Aggregation aggregation = newAggregation(
          group("employee.role").count().as("count"),
          sort(Sort.Direction.DESC,"count"),
          limit(2)
    );

    System.out.println(aggregation);

生成管道：

{ 
    "aggregate" : "__collection__", 
    "pipeline" : [ 
        { "$group" : { 
            "_id" : "$employee.role", 
            "count" : { "$sum" : 1}
        }}, 
        { "$sort" : { "count" : -1} },
        { "$limit" : 2}
    ]
}

关键是你的 $project 用法除了选择一个你以后不使用的字段以及为另一个字段创建别名之外，其他任何事情都没有做到。你还没有真正使用，因为它只是你的分组的_id字段。另请注意使用 $sort ，因为它对 $limit 没有多大意义，除非您有预期订单中的内容，并且 $group 本身并不这样做。

至于解释＆＃34;属性＆＃34;概念，我不是真正的粉丝，那么你可能会考虑以下代码：

    final Aggregation aggregation = newAggregation(
          group("country","employee.role").count().as("count"),
          group("employee.role","count").count().as("totalCount"),
          sort(Sort.Direction.DESC,"totalCount"),
          limit(2)
    );

    System.out.println(aggregation);

然后构造的管道将如下所示：

{ 
    "aggregate" : "__collection__", 
    "pipeline" : [ 
        { "$group" : { 
            "_id" : { 
                "country" : "$country" , 
                "role" : "$employee.role"
            },
            "count" : { "$sum" : 1}
        }}, 
        { "$group" : { 
            "_id" : { 
                "role" : "$_id.employee.role" ,
                "count" : "$count"
            }, 
            "totalCount" : { "$sum" : 1}
        }}, 
        { "$sort" : { "totalCount" : -1} }, 
        { "$limit" : 2 }
    ]
}

因此，虽然这将在没有异常的情况下运行到输出转储，但在生成的管道中仍然存在问题。虽然第一个 $group 语句压缩了子文档字段的别名，但此时所有内容都很好，这是第二个 $group 引入问题的阶段。

构建器方法只是“不开心”＃34;除非您通过完整的＆＃34; employee.role＆＃34;来引用该字段。符号作为原始文件的财产。虽然现在它确实会成为前一阶段_id字段的一部分，但它完全忘记了字段是别名。

对于我的两分钱，这是错误的行为，这也是我不是建筑商忠实粉丝的有力理由。

所以你可以使用它们，但我认为设计尚未完全存在并且存在一些缺陷。同样，对于我的钱来说，使用DBObject类型来构建管道并完成管理似乎更安全，更灵活。至少你知道你总能得到你的意思。

投影后进行组聚合时参考无效

1 个答案: