An example of using Java based bean metadata to register an instance of a com.mongodb.Mongo is shown below

This approach allows you to use the standard com.mongodb.Mongo API that you may already be used to using but also pollutes the code with the UnknownHostException checked exception. The use of the checked exception is not desirable as Java based bean metadata uses methods as a means to set object dependencies, making the calling code cluttered.

An alternative is to register an instance of com.mongodb.Mongo instance with the container using Spring’s` MongoFactoryBean`. As compared to instantiating a com.mongodb.Mongo instance directly, the FactoryBean approach does not throw a checked exception and has the added advantage of also providing the container with an ExceptionTranslator implementation that translates MongoDB exceptions to exceptions in Spring’s portable DataAccessException hierarchy for data access classes annoated with the @Repository annotation. This hierarchy and use of @Repository is described in Spring’s DAO support features.

An example of a Java based bean metadata that supports exception translation on @Repository annotated classes is shown below:

To access the com.mongodb.Mongo object created by the MongoFactoryBean in other @Configuration or your own classes, use a “private @Autowired Mongo mongo;” field.

While you can use Spring’s traditional <beans/> XML namespace to register an instance of com.mongodb.Mongo with the container, the XML can be quite verbose as it is general purpose. XML namespaces are a better alternative to configuring commonly used objects such as the Mongo instance. The mongo namespace alows you to create a Mongo instance server location, replica-sets, and options.

To use the Mongo namespace elements you will need to reference the Mongo schema:

A more advanced configuration with MongoOptions is shown below (note these are not recommended values)

A configuration using replica sets is shown below.

While com.mongodb.Mongo is the entry point to the MongoDB driver API, connecting to a specific MongoDB database instance requires additional information such as the database name and an optional username and password. With that information you can obtain a com.mongodb.DB object and access all the functionality of a specific MongoDB database instance. Spring provides the org.springframework.data.mongodb.core.MongoDbFactory interface shown below to bootstrap connectivity to the database.

The following sections show how you can use the container with either Java or the XML based metadata to configure an instance of the MongoDbFactory interface. In turn, you can use the MongoDbFactory instance to configure MongoTemplate.

The class org.springframework.data.mongodb.core.SimpleMongoDbFactory provides implements the MongoDbFactory interface and is created with a standard com.mongodb.Mongo instance, the database name and an optional org.springframework.data.authentication.UserCredentials constructor argument.

Instead of using the IoC container to create an instance of MongoTemplate, you can just use them in standard Java code as shown below.

The code in bold highlights the use of SimpleMongoDbFactory and is the only difference between the listing shown in the getting started section.

To register a MongoDbFactory instance with the container, you write code much like what was highlighted in the previous code listing. A simple example is shown below

To define the username and password create an instance of org.springframework.data.authentication.UserCredentials and pass it into the constructor as shown below. This listing also shows using MongoDbFactory register an instance of MongoTemplate with the container.

The mongo namespace provides a convient way to create a SimpleMongoDbFactory as compared to using the`<beans/>` namespace. Simple usage is shown below

In the above example a com.mongodb.Mongo instance is created using the default host and port number. The SimpleMongoDbFactory registered with the container is identified by the id 'mongoDbFactory' unless a value for the id attribute is specified.

You can also provide the host and port for the underlying com.mongodb.Mongo instance as shown below, in addition to username and password for the database.

If you need to configure additional options on the com.mongodb.Mongo instance that is used to create a SimpleMongoDbFactory you can refer to an existing bean using the mongo-ref attribute as shown below. To show another common usage pattern, this listing show the use of a property placeholder to parameterise the configuration and creating MongoTemplate.

You can use Java to create and register an instance of MongoTemplate as shown below.

There are several overloaded constructors of MongoTemplate. These are

You can also configure a MongoTemplate using Spring’s XML <beans/> schema.

Other optional properties that you might like to set when creating a MongoTemplate are the default WriteResultCheckingPolicy, WriteConcern, and ReadPreference.

When in development it is very handy to either log or throw an exception if the com.mongodb.WriteResult returned from any MongoDB operation contains an error. It is quite common to forget to do this during development and then end up with an application that looks like it runs successfully but in fact the database was not modified according to your expectations. Set MongoTemplate’s property to an enum with the following values, LOG, EXCEPTION, or NONE to either log the error, throw and exception or do nothing. The default is to use a WriteResultChecking value of NONE.

You can set the com.mongodb.WriteConcern property that the MongoTemplate will use for write operations if it has not yet been specified via the driver at a higher level such as com.mongodb.Mongo. If MongoTemplate’s WriteConcern property is not set it will default to the one set in the MongoDB driver’s DB or Collection setting.

For more advanced cases where you want to set different WriteConcern values on a per-operation basis (for remove, update, insert and save operations), a strategy interface called WriteConcernResolver can be configured on MongoTemplate. Since MongoTemplate is used to persist POJOs, the WriteConcernResolver lets you create a policy that can map a specific POJO class to a WriteConcern value. The WriteConcernResolver interface is shown below.

The passed in argument, MongoAction, is what you use to determine the WriteConcern value to be used or to use the value of the Template itself as a default. MongoAction contains the collection name being written to, the java.lang.Class of the POJO, the converted DBObject, as well as the operation as an enumeration (MongoActionOperation: REMOVE, UPDATE, INSERT, INSERT_LIST, SAVE) and a few other pieces of contextual information. For example,

MongoDB requires that you have an '_id' field for all documents. If you don’t provide one the driver will assign a ObjectId with a generated value. When using the MongoMappingConverter there are certain rules that govern how properties from the Java class is mapped to this '_id' field.

The following outlines what property will be mapped to the '_id' document field:

The following outlines what type conversion, if any, will be done on the property mapped to the _id document field when using the MappingMongoConverter, the default for MongoTemplate.

If no field or property specified above is present in the Java class then an implicit '_id' file will be generated by the driver but not mapped to a property or field of the Java class.

When querying and updating MongoTemplate will use the converter to handle conversions of the Query and Update objects that correspond to the above rules for saving documents so field names and types used in your queries will be able to match what is in your domain classes.

As MongoDB collections can contain documents that represent instances of a variety of types. A great example here is if you store a hierarchy of classes or simply have a class with a property of type Object. In the latter case the values held inside that property have to be read in correctly when retrieving the object. Thus we need a mechanism to store type information alongside the actual document.

To achieve that the MappingMongoConverter uses a MongoTypeMapper abstraction with DefaultMongoTypeMapper as it’s main implementation. It’s default behaviour is storing the fully qualified classname under _class inside the document for the top-level document as well as for every value if it’s a complex type and a subtype of the property type declared.

As you can see we store the type information for the actual root class persistent as well as for the nested type as it is complex and a subtype of Contact. So if you’re now using mongoTemplate.findAll(Object.class, "sample") we are able to find out that the document stored shall be a Sample instance. We are also able to find out that the value property shall be a Person actually.

There are several convenient methods on MongoTemplate for saving and inserting your objects. To have more fine grained control over the conversion process you can register Spring converters with the MappingMongoConverter, for example Converter<Person, DBObject> and Converter<DBObject, Person>.

The simple case of using the save operation is to save a POJO. In this case the collection name will be determined by name (not fully qualfied) of the class. You may also call the save operation with a specific collection name. The collection to store the object can be overriden using mapping metadata.

When inserting or saving, if the Id property is not set, the assumption is that its value will be auto-generated by the database. As such, for auto-generation of an ObjectId to succeed the type of the Id property/field in your class must be either a String, ObjectId, or BigInteger.

Here is a basic example of using the save operation and retrieving its contents.

The insert/save operations available to you are listed below.

A similar set of insert operations is listed below

For updates we can elect to update the first document found using MongoOperation’s method `updateFirst or we can update all documents that were found to match the query using the method updateMulti. Here is an example of an update of all SAVINGS accounts where we are adding a one time $50.00 bonus to the balance using the $inc operator.

In addition to the Query discussed above we provide the update definition using an Update object. The Update class has methods that match the update modifiers available for MongoDB.

As you can see most methods return the Update object to provide a fluent style for the API.

Related to performing an updateFirst operations, you can also perform an upsert operation which will perform an insert if no document is found that matches the query. The document that is inserted is a combination of the query document and the update document. Here is an example

The findAndModify(…) method on DBCollection can update a document and return either the old or newly updated document in a single operation. MongoTemplate provides a findAndModify method that takes Query and Update classes and converts from DBObject to your POJOs. Here are the methods

As an example usage, we will insert of few Person objects into the container and perform a simple findAndUpdate operation

The FindAndModifyOptions lets you set the options of returnNew, upsert, and remove. An example extending off the previous code snippit is shown below

You can use several overloaded methods to remove an object from the database.

We saw how to retrieve a single document using the findOne and findById methods on MongoTemplate in previous sections which return a single domain object. We can also query for a collection of documents to be returned as a list of domain objects. Assuming that we have a number of Person objects with name and age stored as documents in a collection and that each person has an embedded account document with a balance. We can now run a query using the following code.

All find methods take a Query object as a parameter. This object defines the criteria and options used to perform the query. The criteria is specified using a Criteria object that has a static factory method named where used to instantiate a new Criteria object. We recommend using a static import for org.springframework.data.mongodb.core.query.Criteria.where and Query.query to make the query more readable.

This query should return a list of Person objects that meet the specified criteria. The Criteria class has the following methods that correspond to the operators provided in MongoDB.

As you can see most methods return the Criteria object to provide a fluent style for the API.

The query methods need to specify the target type T that will be returned and they are also overloaded with an explicit collection name for queries that should operate on a collection other than the one indicated by the return type.

MongoDB supports GeoSpatial queries through the use of operators such as $near, $within, geoWithin and $nearSphere. Methods specific to geospatial queries are available on the Criteria class. There are also a few shape classes, Box, Circle, and Point that are used in conjunction with geospatial related Criteria methods.

To understand how to perform GeoSpatial queries we will use the following Venue class taken from the integration tests.which relies on using the rich MappingMongoConverter.

To find locations within a Circle, the following query can be used.

To find venues within a Circle using spherical coordinates the following query can be used

To find venues within a Box the following query can be used

To find venues near a Point, the following queries can be used

To find venues near a Point using spherical coordines the following query can be used

MongoDB supports GeoJSON and simple (legacy) coordinate pairs for geospatial data. Those formats can both be used for storing as well as querying data.

Since MongoDB 2.6 full text queries can be executed using the $text operator. Methods and operations specific for full text queries are available in TextQuery and TextCriteria. When doing full text search please refer to the MongoDB reference for its behavior and limitations.

To understand how to perform Map-Reduce operations an example from the book 'MongoDB - The definitive guide' is used. In this example we will create three documents that have the values [a,b], [b,c], and [c,d] respectfully. The values in each document are associated with the key 'x' as shown below. For this example assume these documents are in the collection named "jmr1".

A map function that will count the occurrence of each letter in the array for each document is shown below

The reduce function that will sum up the occurrence of each letter across all the documents is shown below

Executing this will result in a collection as shown below.

Assuming that the map and reduce functions are located in map.js and reduce.js and bundled in your jar so they are available on the classpath, you can execute a map-reduce operation and obtain the results as shown below

The output of the above code is

The MapReduceResults class implements Iterable and provides access to the raw output, as well as timing and count statistics. The ValueObject class is simply

By default the output type of INLINE is used so you don’t have to specify an output collection. To specify additional map-reduce options use an overloaded method that takes an additional MapReduceOptions argument. The class MapReduceOptions has a fluent API so adding additional options can be done in a very compact syntax. Here an example that sets the output collection to "jmr1_out". Note that setting only the output collection assumes a default output type of REPLACE.

There is also a static import import static org.springframework.data.mongodb.core.mapreduce.MapReduceOptions.options; that can be used to make the syntax slightly more compact

You can also specify a query to reduce the set of data that will be used to feed into the map-reduce operation. This will remove the document that contains [a,b] from consideration for map-reduce operations.

Note that you can specify additional limit and sort values as well on the query but not skip values.

In order to understand how group operations work the following example is used, which is somewhat artificial. For a more realistic example consult the book 'MongoDB - The definitive guide'. A collection named "group_test_collection" created with the following rows.

We would like to group by the only field in each row, the 'x' field and aggregate the number of times each specific value of 'x' occurs. To do this we need to create an initial document that contains our count variable and also a reduce function which will increment it each time it is encountered. The Java code to execute the group operation is shown below

The first argument is the name of the collection to run the group operation over, the second is a fluent API that specifies properties of the group operation via a GroupBy class. In this example we are using just the intialDocument and reduceFunction methods. You can also specify a key-function, as well as a finalizer as part of the fluent API. If you have multiple keys to group by, you can pass in a comma separated list of keys.

The raw results of the group operation is a JSON document that looks like this

The document under the "retval" field is mapped onto the third argument in the group method, in this case XObject which is shown below.

You can also obtain the raw result as a DbObject by calling the method getRawResults on the GroupByResults class.

There is an additional method overload of the group method on MongoOperations which lets you specify a Criteria object for selecting a subset of the rows. An example which uses a Criteria object, with some syntax sugar using static imports, as well as referencing a key-function and reduce function javascript files via a Spring Resource string is shown below.

The Aggregation Framework support in Spring Data MongoDB is based on the following key abstractions Aggregation, AggregationOperation and AggregationResults.

Note that if you provide an input class as the first parameter to the newAggregation method the MongoTemplate will derive the name of the input collection from this class. Otherwise if you don’t not specify an input class you must provide the name of the input collection explicitly. If an input-class and an input-collection is provided the latter takes precedence.

The MongoDB Aggregation Framework provides the following types of Aggregation Operations:

At the time of this writing we provide support for the following Aggregation Operations in Spring Data MongoDB.

Note that the aggregation operations not listed here are currently not supported by Spring Data MongoDB. Comparison aggregation operators are expressed as Criteria expressions.

*) The operation is mapped or added by Spring Data MongoDB.

Projection expressions are used to define the fields that are the outcome of a particular aggregation step. Projection expressions can be defined via the project method of the Aggregate class either by passing a list of String`s or an aggregation framework `Fields object. The projection can be extended with additional fields through a fluent API via the and(String) method and aliased via the as(String) method. Note that one can also define fields with aliases via the static factory method Fields.field of the aggregation framework that can then be used to construct a new Fields instance.

Note that more examples for project operations can be found in the AggregationTests class.

Note that further details regarding the projection expressions can be found in the corresponding section of the MongoDB Aggregation Framework reference documentation.

An example implementation of the Converter that converts from a Person object to a com.mongodb.DBObject is shown below

An example implementation of a Converter that converts from a DBObject ot a Person object is shownn below

The Mongo Spring namespace provides a convenience way to register Spring Converter`s with the `MappingMongoConverter. The configuration snippet below shows how to manually register converter beans as well as configuring the wrapping MappingMongoConverter into a MongoTemplate.

You can also use the base-package attribute of the custom-converters element to enable classpath scanning for all Converter and GenericConverter implementations below the given package.

Generally we inspect the Converter implementations for the source and target types they convert from and to. Depending on whether one of those is a type MongoDB can handle natively we will register the converter instance as reading or writing one. Have a look at the following samples:

In case you write a Converter whose source and target type are native Mongo types there’s no way for us to determine whether we should consider it as reading or writing converter. Registering the converter instance as both might lead to unwanted results then. E.g. a Converter<String, Long> is ambiguous although it probably does not make sense to try to convert all String`s into `Long`s when writing. To be generally able to force the infrastructure to register a converter for one way only we provide `@ReadingConverter as well as @WritingConverter to be used at the converter implementation.

We can create an index on a collection to improve query performance.

The IndexOperations interface has the method getIndexInfo that returns a list of IndexInfo objects. This contains all the indexes defined on the collectcion. Here is an example that defines an index on the Person class that has age property.

It’s time to look at some code examples showing how to use the MongoTemplate. First we look at creating our first collection.

The above keywords can be used in conjunciton with delete…By or remove…By to create queries deleting matching documents.

Using return type List will retrieve and return all matching documents before actually deleting them. A numeric return type directly removes the matching documents returning the total number of documents removed.

As you’ve just seen there are a few keywords triggering geo-spatial operations within a MongoDB query. The Near keyword allows some further modification. Let’s have look at some examples:

Adding a Distance parameter to the query method allows restricting results to those within the given distance. If the Distance was set up containing a Metric we will transparently use $nearSphere instead of $code.

As you can see using a Distance equipped with a Metric causes $nearSphere clause to be added instead of a plain $near. Beyond that the actual distance gets calculated according to the Metrics used.

By adding the annotation org.springframework.data.mongodb.repository.Query repository finder methods you can specify a MongoDB JSON query string to use instead of having the query derived from the method name. For example

The placeholder ?0 lets you substitute the value from the method arguments into the JSON query string.

You can also use the filter property to restrict the set of properties that will be mapped into the Java object. For example,

This will return only the firstname, lastname and Id properties of the Person objects. The age property, a java.lang.Integer, will not be set and its value will therefore be null.

MongoDB repository support integrates with the QueryDSL project which provides a means to perform type-safe queries in Java. To quote from the project description, "Instead of writing queries as inline strings or externalizing them into XML files they are constructed via a fluent API." It provides the following features

Please refer to the QueryDSL documentation which describes how to bootstrap your environment for APT based code generation using Maven or using Ant.

Using QueryDSL you will be able to write queries as shown below

QPerson is a class that is generated (via the Java annotation post processing tool) which is a Predicate that allows you to write type safe queries. Notice that there are no strings in the query other than the value "C0123".

You can use the generated Predicate class via the interface QueryDslPredicateExecutor which is shown below

To use this in your repository implementation, simply inherit from it in addition to other repository interfaces. This is shown below

We think you will find this an extremely powerful tool for writing MongoDB queries.

MongoDBs full text search feature is very store specic and therefore can rather be found on MongoRepository than on the more general CrudRepository. What we need is a document with a full-text index defined for (Please see section Text Indexes for creating).

Additional methods on MongoRepository take TextCriteria as input parameter. In addition to those explicit methods, it is also possible to add a TextCriteria derived repository method. The criteria will added as an additional AND criteria. Once the entity contains a @TextScore annotated property the documents full-text score will be retrieved. Furthermore the @TextScore annotated property will also make it possible to sort by the documents score.

Instances of the repository interfaces are usually created by a container, which Spring is the most natural choice when working with Spring Data. As of version 1.3.0 Spring Data MongoDB ships with a custom CDI extension that allows using the repository abstraction in CDI environments. The extension is part of the JAR so all you need to do to activate it is dropping the Spring Data MongoDB JAR into your classpath. You can now set up the infrastructure by implementing a CDI Producer for the MongoTemplate:

The Spring Data MongoDB CDI extension will pick up the MongoTemplate available as CDI bean and create a proxy for a Spring Data repository whenever an bean of a repository type is requested by the container. Thus obtaining an instance of a Spring Data repository is a matter of declaring an @Inject-ed property:

Unresolved directive in index.adoc - include::../../../../spring-data-commons/src/main/asciidoc/auditing.adoc[]

MongoDB requires that you have an '_id' field for all documents. If you don’t provide one the driver will assign a ObjectId with a generated value. The "_id" field can be of any type the, other than arrays, so long as it is unique. The driver naturally supports all primitive types and Dates. When using the MongoMappingConverter there are certain rules that govern how properties from the Java class is mapped to this '_id' field.

The following outlines what field will be mapped to the '_id' document field:

The following outlines what type conversion, if any, will be done on the property mapped to the _id document field.

When querying and updating MongoTemplate will use the converter to handle conversions of the Query and Update objects that correspond to the above rules for saving documents so field names and types used in your queries will be able to match what is in your domain classes.

The MappingMongoConverter can use metadata to drive the mapping of objects to documents. An overview of the annotations is provided below

The mapping metadata infrastructure is defined in a seperate spring-data-commons project that is technology agnostic. Specific subclasses are using in the MongoDB support to support annotation based metadata. Other strategies are also possible to put in place if there is demand.

Here is an example of a more complex mapping.

The mapping subsystem allows the customization of the object construction by annotating a constructor with the @PersistenceConstructor annotation. The values to be used for the constructor parameters are resolved in the following way:

Additional examples for using the @PersistenceConstructor annotation can be found in the MappingMongoConverterUnitTests test suite.

Compound indexes are also supported. They are defined at the class level, rather than on indidividual properties.

Here’s an example that creates a compound index of lastName in ascending order and age in descending order:

Creating a text index allows to accumulate several fields into a searchable full text index. It is only possible to have one text index per collection so all fields marked with @TextIndexed are combined into this index. Properties can be weighted to influence document score for ranking results. The default language for the text index is english, to change the default language set @Document(language="spanish") to any language you want. Using a property called language or @Language allows to define a language override on a per document base.

The mapping framework doesn’t have to store child objects embedded within the document. You can also store them separately and use a DBRef to refer to that document. When the object is loaded from MongoDB, those references will be eagerly resolved and you will get back a mapped object that looks the same as if it had been stored embedded within your master document.

Here’s an example of using a DBRef to refer to a specific document that exists independently of the object in which it is referenced (both classes are shown in-line for brevity’s sake):

There’s no need to use something like @OneToMany because the mapping framework sees that you’re wanting a one-to-many relationship because there is a List of objects. When the object is stored in MongoDB, there will be a list of DBRefs rather than the Account objects themselves.

Events are fired throughout the lifecycle of the mapping process. This is described in the Lifecycle Events section.

Simply declaring these beans in your Spring ApplicationContext will cause them to be invoked whenever the event is dispatched.

When storing and querying your objects it is convenient to have a MongoConverter instance handle the mapping of all Java types to DBObjects. However, sometimes you may want the `MongoConverter’s do most of the work but allow you to selectively handle the conversion for a particular type or to optimize performance.

To selectively handle the conversion yourself, register one or more one or more org.springframework.core.convert.converter.Converter instances with the MongoConverter.

The method customConversions in AbstractMongoConfiguration can be used to configure Converters. The examples here at the beginning of this chapter show how to perform the configuration using Java and XML.

Below is an example of a Spring Converter implementation that converts from a DBObject to a Person POJO.

Here is an example that converts from a Person to a DBObject.

Some of the configuration options have been changed / removed for the mongo-java-driver. The following options will be ignored using the generation 3 driver:

Generally it is recommended to use the <mongo:mongo-client …​ /> and <mongo:client-options …​ /> elements instead of <mongo:mongo …​ /> when doing XML based configuration, since those elements will only provide you with attributes valid for the 3 generation java driver.

The WriteConcern.NONE, which had been used as default by Spring Data MongoDB, was removed in 3.0. Therefore in a MongoDB 3 environment the WriteConcern will be defaulted to WriteConcern.UNACKNOWLEGED. In case WriteResultChecking.EXCEPTION is enabled the WriteConcern will be altered to WriteConcern.ACKNOWLEDGED for write operations, as otherwise errors during execution would not be throw correctly, since simply not raised by the driver.

MongoDB Server generation 3 changed the authentication model when connecting to the DB. Therefore some of the configuration options available for authentication are no longer valid. Please use the MongoClient specific options for setting credentials via MongoCredential to provide authentication data.

In order to use authentication with XML configuration use the credentials attribue on <mongo-client>.

This section covers additional things to keep in mind when using the 3.0 driver.