logo标签列表

在投影后进行分组聚合时出现无效引用错误

javaspring-dataspring-data-mongodb
6

这个聚合示例会抛出一个IllegalArgumentException，错误信息为"Invalid reference 'role'!"。

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

    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
           }

    } 
}

思路:

这里 Oliver说：

重要的是要明白，你是按照类型属性而不是文档字段名称来定义聚合。

是否这就是我们得到异常的原因？如果是，如何使用Spring Data提供的优质聚合API。

更新::

这是我使用版本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)
你使用的是哪个版本？你得到了什么精确的堆栈跟踪？ - Oliver Drotbohm
我已经在1.5.0.M1中添加了Stacktrace。(在旧版本中也是一样的) - d0x
1个回答
2

确实，实现方式不喜欢你在这里所做的字段别名类型，但在最严格的解释下，你所做的并没有太多意义。

你的陈述应该是这样的：

    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本身并不能做到这一点。
至于解释“属性”概念，我并不是很喜欢，你可以考虑以下代码：
    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阶段引入了问题。
构建器方法只有在您将该字段作为原始文档的属性的完整"employee.role"符号表示法引用时才会“感到高兴”。尽管它确实可以从先前阶段的_id字段中获取该字段，但它完全忘记了该字段已被命名为别名。
对我来说，这是错误的行为，也是我不太喜欢构建器的一个重要原因。
因此，您可以使用它们，但我认为设计还没有完全到位，存在一些缺陷。再次强调，对于我的钱来说，使用DBObject类型构建管道并完成工作似乎更安全、更灵活。至少你知道你总是得到你想要的东西。
是的，你说得对。在这个例子中，我进行了一个“无用”的投影。当时写问题时我没有注意到这一点。无论如何，我试图指出的关键是，在对类型进行投影之后，我不能在另一个分组阶段中使用投影的“字段”。 - d0x
@ChristianSchneider 是的。我想指出的主要问题是当前API存在问题，因此请改用DBObject构造形式。同时还有一个要点，即如果以不同方式构造语句，则当前API仍然可以正常工作。总之，对我来说，这似乎是一个明确的答案。 - Neil Lunn
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接