java引用聚合,java – 投影后进行组聚合时的无效引用

此示例聚合将抛出IllegalArgumentException无效的引用“角色”！

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

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奥利弗说

It’s important to understand that you define aggregations in terms of type properties, not document field names.

这就是我们获得例外的原因吗？如果是这样,如何使用漂亮的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)

解决方法:

确实,实现“不喜欢”你在这里做的字段别名类型,但是在最严格的解释中,你所做的事情没有多大意义.

你的陈述应该是这样的：

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}

]

}

关键是你的$项目在这里没有做任何事情,除了选择你以后不使用的一个字段,并为另一个你还没用的字段创建一个别名,因为它只是成为了_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类型来构建管道并完成它似乎更安全,更灵活.至少你知道你总能得到你的意思.

标签：java,spring-data,spring-data-mongodb

来源： https://codeday.me/bug/20190703/1364860.html