The following example shows an example of using Java-based bean metadata to register an instance of a com.mongodb.MongoClient:

This approach lets you use the standard com.mongodb.MongoClient instance, with the container using Spring’s MongoClientFactoryBean. As compared to instantiating a com.mongodb.MongoClient instance directly, the FactoryBean 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 annotated with the @Repository annotation. This hierarchy and the use of @Repository is described in Spring’s DAO support features.

The following example shows an example of a Java-based bean metadata that supports exception translation on @Repository annotated classes:

To access the com.mongodb.MongoClient object created by the MongoClientFactoryBean in other @Configuration classes 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.MongoClient 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 lets you create a Mongo instance server location, replica-sets, and options.

To use the Mongo namespace elements, you need to reference the Mongo schema, as follows:

The following example shows a more advanced configuration with MongoClientOptions (note that these are not recommended values):

The following example shows a configuration using replica sets:

While com.mongodb.MongoClient 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.client.MongoDatabase object and access all the functionality of a specific MongoDB database instance. Spring provides the org.springframework.data.mongodb.core.MongoDbFactory interface, shown in the following listing, to bootstrap connectivity to the database:

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

Instead of using the IoC container to create an instance of MongoTemplate, you can use them in standard Java code, as follows:

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. The following listing shows a simple example:

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. You should use the MongoClient-specific options for setting credentials through MongoCredential to provide authentication data, as shown in the following example:

In order to use authentication with XML-based configuration, use the credentials attribute on the <mongo-client> element.

As of MongoDB java driver 3.7.0 there is an alternative entry point to MongoClient via the mongodb-driver-sync artifact. com.mongodb.client.MongoClient is not compatible with com.mongodb.MongoClient and does not longer support the legacy DBObject codec. Therefore, it cannot be used with Querydsl and requires a different configuration. You can use AbstractMongoClientConfiguration to leverage the new MongoClients builder API.

The mongo namespace provides a convenient way to create a SimpleMongoDbFactory, as compared to using the <beans/> namespace, as shown in the following example:

If you need to configure additional options on the com.mongodb.MongoClient instance that is used to create a SimpleMongoDbFactory, you can refer to an existing bean by using the mongo-ref attribute as shown in the following example. To show another common usage pattern, the following listing shows the use of a property placeholder, which lets you parametrize the configuration and the creation of a MongoTemplate:

You can use Java to create and register an instance of MongoTemplate, as the following example shows:

There are several overloaded constructors of MongoTemplate:

You can also configure a MongoTemplate by using Spring’s XML <beans/> schema, as the following example shows:

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

When in development, it is 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 when, in fact, the database was not modified according to your expectations. You can set the WriteResultChecking property of MongoTemplate to one of the following values: EXCEPTION or NONE, to either throw an Exception or do nothing, respectively. The default is to use a WriteResultChecking value of NONE.

If it has not yet been specified through the driver at a higher level (such as com.mongodb.MongoClient), you can set the com.mongodb.WriteConcern property that the MongoTemplate uses for write operations. If the WriteConcern property is not set, it defaults 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 following listing shows the WriteConcernResolver interface:

You can use the MongoAction argument to determine the WriteConcern value or 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 Document, the operation (REMOVE, UPDATE, INSERT, INSERT_LIST, or SAVE), and a few other pieces of contextual information. The following example shows two sets of classes getting different WriteConcern settings:

MongoDB requires that you have an _id field for all documents. If you do not provide one, the driver assigns an ObjectId with a generated value. When you use the MappingMongoConverter, certain rules govern how properties from the Java class are mapped to this _id field:

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

If no field or property specified in the previous sets of rules is present in the Java class, an implicit _id file is generated by the driver but not mapped to a property or field of the Java class.

When querying and updating, MongoTemplate uses the converter that corresponds to the preceding rules for saving documents so that field names and types used in your queries can match what is in your domain classes.

Some environments require a customized approach to map Id values such as data stored in MongoDB that did not run through the Spring Data mapping layer. Documents can contain _id values that can be represented either as ObjectId or as String. Reading documents from the store back to the domain type works just fine. Querying for documents via their id can be cumbersome due to the implicit ObjectId conversion. Therefore documents cannot be retrieved that way. For those cases @MongoId provides more control over the actual id mapping attempts.

MongoDB collections can contain documents that represent instances of a variety of types. This feature can be useful if you store a hierarchy of classes or 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 its main implementation. Its default behavior to store the fully qualified classname under _class inside the document. Type hints are written for top-level documents as well as for every value (if it is a complex type and a subtype of the declared property type). The following example (with a JSON representation at the end) shows how the mapping works:

Spring Data MongoDB stores the type information as the last field for the actual root class as well as for the nested type (because it is complex and a subtype of Contact). So, if you now use mongoTemplate.findAll(Object.class, "sample"), you can find out that the document stored is a Sample instance. You can also find out that the value property is actually a Person.

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, Document> and Converter<Document, Person>.

The simple case of using the save operation is to save a POJO. In this case, the collection name is determined by name (not fully qualified) of the class. You may also call the save operation with a specific collection name. You can use mapping metadata to override the collection in which to store the object.

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

The following example shows how to save a document and retrieving its contents:

The following insert and save operations are available:

A similar set of insert operations is also available:

For updates, you can update the first document found by using MongoOperation.updateFirst or you can update all documents that were found to match the query by using the MongoOperation.updateMulti method. The following example shows an update of all SAVINGS accounts where we are adding a one-time $50.00 bonus to the balance by using the $inc operator:

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

Most methods return the Update object to provide a fluent style for the API.

Related to performing an updateFirst operation, 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. The following example shows how to use the upsert method:

The findAndModify(…) method on MongoCollection can update a document and return either the old or newly updated document in a single operation. MongoTemplate provides four findAndModify overloaded methods that take Query and Update classes and converts from Document to your POJOs:

The following example inserts a few Person objects into the container and performs a findAndUpdate operation:

The FindAndModifyOptions method lets you set the options of returnNew, upsert, and remove. An example extending from the previous code snippet follows:

The most straight forward method of replacing an entire Document is via its id using the save method. However this might not always be feasible. findAndReplace offers an alternative that allows to identify the document to replace via a simple query.

You can use one of five overloaded methods to remove an object from the database:

The @Version annotation provides syntax similar to that of JPA in the context of MongoDB and makes sure updates are only applied to documents with a matching version. Therefore, the actual value of the version property is added to the update query in such a way that the update does not have any effect if another operation altered the document in the meantime. In that case, an OptimisticLockingFailureException is thrown. The following example shows these features:

Earlier, we saw how to retrieve a single document by using the findOne and findById methods on MongoTemplate. These methods 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 are specified by using a Criteria object that has a static factory method named where to instantiate a new Criteria object. We recommend using static imports for org.springframework.data.mongodb.core.query.Criteria.where and Query.query to make the query more readable.

The query should return a list of Person objects that meet the specified criteria. The rest of this section lists the methods of the Criteria and Query classes that correspond to the operators provided in MongoDB. 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 is returned, and they are overloaded with an explicit collection name for queries that should operate on a collection other than the one indicated by the return type. The following query methods let you find one or more documents:

MongoDB provides an operation to obtain distinct values for a single field by using a query from the resulting documents. Resulting values are not required to have the same data type, nor is the feature limited to simple types. For retrieval, the actual result type does matter for the sake of conversion and typing. The following example shows how to query for distinct values:

Retrieving distinct values into a Collection of Object is the most flexible way, as it tries to determine the property value of the domain type and convert results to the desired type or mapping Document structures.

Sometimes, when all values of the desired field are fixed to a certain type, it is more convenient to directly obtain a correctly typed Collection, as shown in the following example:

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, consider the following Venue class (taken from the integration tests and relying on the rich MappingMongoConverter):

To find locations within a Circle, you can use the following query:

To find venues within a Circle using spherical coordinates, you can use the following query:

To find venues within a Box, you can use the following query:

To find venues near a Point, you can use the following queries:

To find venues near a Point using spherical coordinates, you can use the following query:

MongoDB supports GeoJSON and simple (legacy) coordinate pairs for geospatial data. Those formats can both be used for storing as well as querying data. See the MongoDB manual on GeoJSON support to learn about requirements and restrictions.

Since version 2.6 of MongoDB, you can run full-text queries by using the $text operator. Methods and operations specific to full-text queries are available in TextQuery and TextCriteria. When doing full text search, see the MongoDB reference for its behavior and limitations.

Since version 3.4, MongoDB supports collations for collection and index creation and various query operations. Collations define string comparison rules based on the ICU collations. A collation document consists of various properties that are encapsulated in Collation, as the following listing shows:

Collations can be used to create collections and indexes. If you create a collection that specifies a collation, the collation is applied to index creation and queries unless you specify a different collation. A collation is valid for a whole operation and cannot be specified on a per-field basis.

Like other metadata, collations can be be derived from the domain type via the collation attribute of the @Document annotation and will be applied directly when executing queries, creating collections or indexes.

Using collations with collection operations is a matter of specifying a Collation instance in your query or operation options, as the following two examples show:

As of version 3.6, MongoDB supports collections that validate documents against a provided JSON Schema. The schema itself and both validation action and level can be defined when creating the collection, as the following example shows:

You can provide a schema either by specifying a schema document (that is, by using the Document API to parse or build a document object) or by building it with Spring Data’s JSON schema utilities in org.springframework.data.mongodb.core.schema. MongoJsonSchema is the entry point for all JSON schema-related operations. The following example shows how use MongoJsonSchema.builder() to create a JSON schema:

There are already some predefined and strongly typed schema objects (JsonSchemaObject and JsonSchemaProperty) available through static methods on the gateway interfaces. However, you may need to build custom property validation rules, which can be created through the builder API, as the following example shows:

CollectionOptions provides the entry point to schema support for collections, as the following example shows:

You can use a schema to query any collection for documents that match a given structure defined by a JSON schema, as the following example shows:

The following table shows the supported JSON schema types:

For more information, see $jsonSchema.

The MongoOperations interface is one of the central components when it comes to more low-level interaction with MongoDB. It offers a wide range of methods covering needs from collection creation, index creation, and CRUD operations to more advanced functionality, such as Map-Reduce and aggregations. You can find multiple overloads for each method. Most of them cover optional or nullable parts of the API.

FluentMongoOperations provides a more narrow interface for the common methods of MongoOperations and provides a more readable, fluent API. The entry points (insert(…), find(…), update(…), and others) follow a natural naming schema based on the operation to be run. Moving on from the entry point, the API is designed to offer only context-dependent methods that lead to a terminating method that invokes the actual MongoOperations counterpart — the all method in the case of the following example:

Sometimes, a collection in MongoDB holds entities of different types, such as a Jedi within a collection of SWCharacters. To use different types for Query and return value mapping, you can use as(Class<?> targetType) to map results differently, as the following example shows:

You can switch between retrieving a single entity and retrieving multiple entities as a List or a Stream through the terminating methods: first(), one(), all(), or stream().

When writing a geo-spatial query with near(NearQuery), the number of terminating methods is altered to include only the methods that are valid for executing a geoNear command in MongoDB (fetching entities as a GeoResult within GeoResults), as the following example shows:

Kotlin embraces domain-specific language creation through its language syntax and its extension system. Spring Data MongoDB ships with a Kotlin Extension for Criteria using Kotlin property references to build type-safe queries. Queries using this extension are typically benefit from improved readability. Most keywords on Criteria have a matching Kotlin extension, such as inValues and regex.

Consider the following example explaining Type-safe Queries:

MongoDB offers various ways of applying meta information, like a comment or a batch size, to a query. Using the Query API directly there are several methods for those options.

On the repository level the @Meta annotation provides means to add query options in a declarative way.

Unresolved directive in reference/mongodb.adoc - include::../../../../../../spring-data-commons/src/main/asciidoc/query-by-example.adoc[leveloffset=+1] :leveloffset: +1

To understand how to perform Map-Reduce operations, we use an example from the book, MongoDB - The Definitive Guide ^[1]. In this example, we create three documents that have the values [a,b], [b,c], and [c,d], respectively. The values in each document are associated with the key, 'x', as the following example shows (assume these documents are in a collection named jmr1):

The following map function counts the occurrence of each letter in the array for each document:

The follwing reduce function sums up the occurrence of each letter across all the documents:

Running the preceding functions result in the following collection:

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 run a Map-Reduce operation as follows:

The preceding exmaple produces the following output:

The MapReduceResults class implements Iterable and provides access to the raw output and timing and count statistics. The following listing shows the ValueObject class:

By default, the output type of INLINE is used so that you need not 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 compact syntax. The following example 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, as the following example shows:

You can also specify a query to reduce the set of data that is fed into the Map-Reduce operation. The following example removes the document that contains [a,b] from consideration for Map-Reduce operations:

Note that you can specify additional limit and sort values on the query, but you cannot 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 Document 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 derives the name of the input collection from this class. Otherwise, if you do not not specify an input class, you must provide the name of the input collection explicitly. If both an input class and an input collection are 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.

Projection expressions are used to define the fields that are the outcome of a particular aggregation step. Projection expressions can be defined through the project method of the Aggregation class, either by passing a list of String objects or an aggregation framework Fields object. The projection can be extended with additional fields through a fluent API by using the and(String) method and aliased by using the as(String) method. Note that you can also define fields with aliases by using the Fields.field static factory method of the aggregation framework, which you can then use to construct a new Fields instance. References to projected fields in later aggregation stages are valid only for the field names of included fields or their aliases (including newly defined fields and their aliases). Fields not included in the projection cannot be referenced in later aggregation stages. The following listings show examples of projection expression:

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.

As of Version 3.4, MongoDB supports faceted classification by using the Aggregation Framework. A faceted classification uses semantic categories (either general or subject-specific) that are combined to create the full classification entry. Documents flowing through the aggregation pipeline are classified into buckets. A multi-faceted classification enables various aggregations on the same set of input documents, without needing to retrieve the input documents multiple times.

The most trivial way of influencing the the mapping result is by specifying the desired native MongoDB target type via the @Field annotation. This allows to work with non MongoDB types like BigDecimal in the domain model while persisting values in native org.bson.types.Decimal128 format.

The snippet above is handy for providing simple type hints. To gain more fine-grained control over the mapping process, you can register Spring converters with the MongoConverter implementations, such as the MappingMongoConverter.

The MappingMongoConverter checks to see if any Spring converters can handle a specific class before attempting to map the object itself. To 'hijack' the normal mapping strategies of the MappingMongoConverter, perhaps for increased performance or other custom mapping needs, you first need to create an implementation of the Spring Converter interface and then register it with the MappingConverter.

You can create an index on a collection to improve query performance by using the MongoTemplate class, as the following example shows:

ensureIndex makes sure that an index for the provided IndexDefinition exists for the collection.

You can create standard, geospatial, and text indexes by using the IndexDefinition, GeoSpatialIndex and TextIndexDefinition classes. For example, given the Venue class defined in a previous section, you could declare a geospatial query, as the following example shows:

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

The following example shows how to create a collection:

Listening to a capped collection using a Sync Driver creates a long running, blocking task that needs to be delegated to a separate component. In this case, we need to first create a MessageListenerContainer, which will be the main entry point for running the specific SubscriptionRequest. Spring Data MongoDB already ships with a default implementation that operates on MongoTemplate and is capable of creating and executing Task instances for a TailableCursorRequest.

The following example shows how to use tailable cursors with MessageListener instances:

Using tailable cursors with a reactive data types allows construction of infinite streams. A tailable cursor remains open until it is closed externally. It emits data as new documents arrive in a capped collection.

Tailable cursors may become dead, or invalid, if either the query returns no match or the cursor returns the document at the “end” of the collection and the application then deletes that document. The following example shows how to create and use an infinite stream query:

Spring Data MongoDB Reactive repositories support infinite streams by annotating a query method with @Tailable. This works for methods that return Flux and other reactive types capable of emitting multiple elements, as the following example shows:

Listening to a Change Stream by using a Sync Driver creates a long running, blocking task that needs to be delegated to a separate component. In this case, we need to first create a MessageListenerContainer, which will be the main entry point for running the specific SubscriptionRequest tasks. Spring Data MongoDB already ships with a default implementation that operates on MongoTemplate and is capable of creating and executing Task instances for a ChangeStreamRequest.

The following example shows how to use Change Streams with MessageListener instances:

Subscribing to Change Streams with the reactive API is a more natural approach to work with streams. Still, the essential building blocks, such as ChangeStreamOptions, remain the same. The following example shows how to use Change Streams emitting ChangeStreamEvents:

Change Streams can be resumed and resume emitting events where you left. To resume the stream, you need to supply either a resume token or the last known server time (in UTC). Use ChangeStreamOptions to set the value accordingly.

The following example shows how to set the resume offset using server time:

The following example shows how to use Java-based bean metadata to register an instance of a com.mongodb.reactivestreams.client.MongoClient:

This approach lets you use the standard com.mongodb.reactivestreams.client.MongoClient API (which you may already know).

An alternative is to register an instance of com.mongodb.reactivestreams.client.MongoClient instance with the container by using Spring’s ReactiveMongoClientFactoryBean. As compared to instantiating a com.mongodb.reactivestreams.client.MongoClient instance directly, the FactoryBean approach 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 annotated with the @Repository annotation. This hierarchy and use of @Repository is described in Spring’s DAO support features.

The following example shows Java-based bean metadata that supports exception translation on @Repository annotated classes:

To access the com.mongodb.reactivestreams.client.MongoClient object created by the ReactiveMongoClientFactoryBean in other @Configuration or your own classes, get the MongoClient from the context.

While com.mongodb.reactivestreams.client.MongoClient is the entry point to the reactive MongoDB driver API, connecting to a specific MongoDB database instance requires additional information, such as the database name. With that information, you can obtain a com.mongodb.reactivestreams.client.MongoDatabase object and access all the functionality of a specific MongoDB database instance. Spring provides the org.springframework.data.mongodb.core.ReactiveMongoDatabaseFactory interface to bootstrap connectivity to the database. The following listing shows the ReactiveMongoDatabaseFactory interface:

The org.springframework.data.mongodb.core.SimpleReactiveMongoDatabaseFactory class implements the ReactiveMongoDatabaseFactory interface and is created with a standard com.mongodb.reactivestreams.client.MongoClient instance and the database name.

Instead of using the IoC container to create an instance of ReactiveMongoTemplate, you can use them in standard Java code, as follows:

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

To register a ReactiveMongoDatabaseFactory instance with the container, you can write code much like what was highlighted in the previous code listing, as the following example shows:

To define the username and password, create a MongoDB connection string and pass it into the factory method, as the next listing shows. The following listing also shows how to use ReactiveMongoDatabaseFactory to register an instance of ReactiveMongoTemplate with the container:

You can use Java to create and register an instance of ReactiveMongoTemplate, as follows:

There are several overloaded constructors of ReactiveMongoTemplate, including:

When creating a ReactiveMongoTemplate, you might also want to set the following properties:

When in development, it is 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 when, in fact, the database was not modified according to your expectations. Set the MongoTemplate WriteResultChecking 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.

If it has not yet been specified through the driver at a higher level (such as MongoDatabase), you can set the com.mongodb.WriteConcern property that the ReactiveMongoTemplate uses for write operations. If ReactiveMongoTemplate’s WriteConcern property is not set, it defaults to the one set in the MongoDB driver’s MongoDatabase or MongoCollection 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 ReactiveMongoTemplate. Since ReactiveMongoTemplate is used to persist POJOs, the WriteConcernResolver lets you create a policy that can map a specific POJO class to a WriteConcern value. The following listing shows the WriteConcernResolver interface:

The argument, MongoAction, determines the WriteConcern value to be used and whether 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, the operation as a value from the MongoActionOperation enumeration (one of REMOVE, UPDATE, INSERT, INSERT_LIST, and SAVE), and a few other pieces of contextual information. The following example shows how to create a WriteConcernResolver: