Support for map-reduce operations in MongoTemplate [DATAMONGO-7] about spring-data-mongodb

[spring-projects-issues]

Matthias Scudlik commented

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

[spring-projects-issues]

Mark Pollack commented

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

[spring-projects-issues]

Matthias Scudlik commented

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?

[spring-projects-issues]

Mark Pollack commented

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

[spring-projects-issues]

Matthias Scudlik commented

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

[spring-projects-issues]

Mark Pollack commented

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...
}

options().output(MapReduceOutput.replace(collectionName))
options().output(replace(collectionName))

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

options().finalize(finalize)

etc...

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?

[spring-projects-issues]

Matthias Scudlik commented

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.

Note:
You probably need some placeholders in the .js files