You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for exploring that path. We generally advocate for our Aggregation Framework API to rather use programmatic guidance as aggregations can become pretty complex with their variety of options.
String-based aggregations with bindings pose two parts: Parsing stages into string and declaring bind-values.
Spring has traditionally provided by-index and by-name bindings.
Taking a step back, we wanted to introduce many more variants of expressing predicates by using e.g. Querydsl. So this is an interesting approach and should not be limited to Aggregations. We just don't know when we would be ready to explore additional variants to form queries.
For the time being it is good that the code lives on your side and once it has proven useful, we can continue that discussion.
I'm currently converting aggregations pipelines from
MongoRepository
to concrete classes withMongoTemplate
, due to #4808, among other issues.In repositories, you can write pipelines as an array of json strings with placeholders for parameter binding:
This is easy enough to port to an
Aggregation
to use withMongoTemplate
, but it can become quite burdensome for more complex pipelines.To simplify the process, I have created a couple helper classes,
shamelessly copyingtaking inspiration from StringAggregationOperation (which is not public) combined with BindableMongoExpression:This can be used as follows:
And supports type and properties conversion as well as parameter binding.
Is this a feature the Spring Data MongoDB project would be interested in?
The text was updated successfully, but these errors were encountered: