Spring数据mongodb应用程序设计和数据聚合

Question

我正在用spring data mongo和angularjs开发一个小应用程序。这是模型：

public class Lease {
        @Id
        private String id;
        private long created;
        private Lessor lessor;
        private Lessee lessee;
      }

public class Payment {
        @Id
        private String id;
        private Integer month;
        private Integer year;
        private Long amount;
        private String leaseId;
     }

我没有嵌入支付模型，因为我需要它有一个id并以自己的形式编辑它。在应用程序的主页面上，它代表按月付款的租约列表。在列表上方的选择中选择年份。

如何使用休息逐月更好地加载租金：可能是先加载租约然后注入付款或有更好的解决方案？目前我选择使用聚合：

LookupOperation lookupOperation = LookupOperation.newLookup().
                                  from("payment").
                                  localField("leaseId").
                                  foreignField("id").
                                  as("payments");

AggregationOperation match = Aggregation.match(Criteria.where("payments.year").is(year));
Aggregation aggregation = Aggregation.newAggregation(lookupOperation, match);

return mongoOperations.aggregate(aggregation, "lease", LeaseAggregation.class).getMappedResults();

问题是匹配在这里是排他性的，例如，如果2017年没有付款，则租约清单为空。我在mongo中看到了“addFields”功能尚未在spring数据mongodb中实现。对我来说更好的json回报是：

{"leases" : [{"id" : 123, "created" : 12324343434, "payments" : [123, 455, 343, 323, 344, null, null, 332, 323, 232, 333, 434}]}

付款将代表特定年份的十二个月。

如何通过spring数据mongodb获得这个？

任何帮助，将不胜感激！

Answer 1

每当Spring Data Mongo缺少你需要的AggregationOperation（重现$addFields，$redact ......）时，一种解决方法（有些人可能会说快速而肮脏的解决方案）是将原始聚合传递给Spring，直接使用com.mongodb.client工具：

String collectionName = mongoTemplate.getCollectionName(Payment.class);
MongoCollection<Document> collection = mongoClient.getDatabase(mongoTemplate.getDb().getName()).getCollection(collectionName);

AggregateIterable<Document> ai = collection.aggregate(Arrays.asList(
    Document.parse(/* { "group" : { ... } } */)))

MongoCollection.aggregate（）作为List<Document>传递聚合管道（事实上List<? extends Bson>是原始形式，如上所述使用Document.parse（），你当然也可以使用new Document()使它看起来更像正确的OOP代码。我倾向于当原始聚合很复杂时使用原始表单，或者嵌套Document的嵌套组件对我来说太多冗长，但这是一个品味问题。