[DATAMONGO-7] Support for map-reduce operations in MongoTemplate Created: 01/Dec/10  Updated: 25/Mar/13  Resolved: 01/Sep/11

Status: Closed
Project: Spring Data MongoDB
Component/s: Core
Affects Version/s: None
Fix Version/s: 1.0 M4

Type: New Feature Priority: Major
Reporter: Mark Pollack Assignee: Mark Pollack
Resolution: Complete Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloned from DATAMONGO-182 add 'group' and 'mapreduce' to the Mo... Closed
Last updater: Trevor Marshall


The use of MapReduce via the driver is cumbersome, provide a layer that exposes map reduce operations with type-safe helper objects.

Investigate: http://cookbook.mongodb.org/ lists a few common cases where one would use map-reduce, typically to sort/count document array elements. See how this might be better packaged up so as to avoid Java users from having to write JavaScript/MapReduce for common tasks.

Comment by Matthias Scudlik [ 05/Apr/11 ]

group by (like sql) integration with min/max/sum etc. in the Criteria API would be very useful

Comment by Mark Pollack [ 05/Apr/11 ]

looks like 1.9 will have this - http://jira.mongodb.org/browse/SERVER-447

Comment by Matthias Scudlik [ 06/Apr/11 ]

Will this be added to the Criteria API, once 1.9 is out?
How do you handle that spring-document-mongodb is compatible to various mongodb versions?

Comment by Mark Pollack [ 29/Aug/11 ]

I think we will add features into the API to track the latest releases, these would then fail on an older server. Documenting this seems enough for now I think, we could add some server number checks as well. FWIW, the aggregation framework was move to 2.1, due date is now in Oct 2011.

Comment by Matthias Scudlik [ 29/Aug/11 ]

I think you're right, but only with the new aggregation framework. All of these features can be done with map reduce as well i think. So the question is whether you can reverse engineer parts of it with map reduce

Comment by Mark Pollack [ 29/Aug/11 ]

The API i'm thinking of implementing is looking like like what is in the C# driver.

<T> MapReduceResult<T> mapReduce(String map, String reduce, Class<T> entityClass )

<T> MapReduceResult<T> mapReduce(String map, String reduce, MapReduceOptions options, Class<T> entityClass )

<T> MapReduceResult<T> mapReduce(Query query, String map, String reduce, Class<T> entityClass)

<T> MapReduceResult<T> mapReduce(Query query, String map, String reduce, MapReduceOptions options, Class<T> entityClass)

where you can create MapReduceOptions in a fluent API style like this

public static MapReduceOptions options()

{ return new MapReduceOptions() }

// possible pass in some common options in a ctor arg

public static MapReduceOutput replace(String collectionName) {
new MapReduceOutput...


//default is replace
options().output(collectionName, databaseName))



Strings will be attempted to be converted to a Spring resource URI so they can be picked up via the classpath or such this way map and reduce .js files can live separately.

Using an extended criteria API just for map reduce, e.g. min-max might be possible in that one could generate the .js files on the fly for simple cases. I'd need to play with it a bit more as the more I dig into it the more delicate it seems to provide a general solution.

What do you think?

Comment by Matthias Scudlik [ 30/Aug/11 ]

I think this is a good solution. One can provide .js files for own UseCases but you also support the common functions like min and max.

You probably need some placeholders in the .js files

Generated at Fri Jul 19 11:03:24 UTC 2019 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.