Rich mapping support is provided by the MappingMongoConverter. MappingMongoConverter has a rich metadata model that provides a full feature set to map domain objects to MongoDB documents.
The mapping metadata model is populated by using annotations on your domain objects.
However, the infrastructure is not limited to using annotations as the only source of metadata information.
The MappingMongoConverter also lets you map objects to documents without providing any additional metadata, by following a set of conventions.
This section describes the features of the MappingMongoConverter, including fundamentals, how to use conventions for mapping objects to documents and how to override those conventions with annotation-based mapping metadata.
MappingMongoConverter has a few conventions for mapping objects to documents when no additional mapping metadata is provided. The conventions are:
-
The short Java class name is mapped to the collection name in the following manner. The class
com.bigbank.SavingsAccountmaps to thesavingsAccountcollection name. -
All nested objects are stored as nested objects in the document and not as DBRefs.
-
The converter uses any Spring Converters registered with it to override the default mapping of object properties to document fields and values.
-
The fields of an object are used to convert to and from fields in the document. Public
JavaBeanproperties are not used. -
If you have a single non-zero-argument constructor whose constructor argument names match top-level field names of document, that constructor is used. Otherwise, the zero-argument constructor is used. If there is more than one non-zero-argument constructor, an exception will be thrown.
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 MappingMongoConverter 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:
-
A field annotated with
@Id(org.springframework.data.annotation.Id) will be mapped to the_idfield. -
A field without an annotation but named
idwill be mapped to the_idfield. -
The default field name for identifiers is
_idand can be customized via the@Fieldannotation.
_id field definitions
| Field definition | Resulting Id-Fieldname in MongoDB |
|---|---|
|
|
|
|
|
|
|
|
|
|
The following outlines what type conversion, if any, will be done on the property mapped to the _id document field.
-
If a field named
idis declared as a String or BigInteger in the Java class it will be converted to and stored as an ObjectId if possible. ObjectId as a field type is also valid. If you specify a value foridin your application, the conversion to an ObjectId is detected to the MongoDB driver. If the specifiedidvalue cannot be converted to an ObjectId, then the value will be stored as is in the document’s _id field. This also applies if the field is annotated with@Id. -
If a field is annotated with
@MongoIdin the Java class it will be converted to and stored as using its actual type. No further conversion happens unless@MongoIddeclares a desired field type. -
If a field is annotated with
@MongoId(FieldType.…)in the Java class it will be attempted to convert the value to the declaredFieldType. -
If a field named
idid field is not declared as a String, BigInteger, or ObjectID in the Java class then you should assign it a value in your application so it can be stored 'as-is' in the document’s _id field. -
If no field named
idis present in the Java class then an implicit_idfile 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.
This section explains how types are mapped to and from a MongoDB representation. Spring Data MongoDB supports all types that can be represented as BSON, MongoDB’s internal document format. In addition to these types, Spring Data MongoDB provides a set of built-in converters to map additional types. You can provide your own converters to adjust type conversion. See [mapping-explicit-converters] for further details.
The following provides samples of each available type conversion:
| Type | Type conversion | Sample |
|---|---|---|
|
native |
|
|
native |
|
|
native |
|
|
native |
|
|
native |
|
|
native |
|
|
native |
|
|
native |
|
|
native |
|
Array, |
native |
|
|
native |
|
|
native |
|
|
native |
|
|
native |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
native |
|
|
converter |
|
|
converter / native (Java8)[1] |
|
|
converter / native (Java8)[2] |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
|
converter |
|
Unless explicitly configured, an instance of MappingMongoConverter is created by default when you create a MongoTemplate. You can create your own instance of the MappingMongoConverter. Doing so lets you dictate where in the classpath your domain classes can be found, so that Spring Data MongoDB can extract metadata and construct indexes. Also, by creating your own instance, you can register Spring converters to map specific classes to and from the database.
You can configure the MappingMongoConverter as well as com.mongodb.client.MongoClient and MongoTemplate by using either Java-based or XML-based metadata. The following example uses Spring’s Java-based configuration:
@Configuration
public class MongoConfig extends AbstractMongoClientConfiguration {
@Override
public String getDatabaseName() {
return "database";
}
// the following are optional
@Override
public String getMappingBasePackage() { (1)
return "com.bigbank.domain";
}
@Override
void configureConverters(MongoConverterConfigurationAdapter adapter) { (2)
adapter.registerConverter(new org.springframework.data.mongodb.test.PersonReadConverter());
adapter.registerConverter(new org.springframework.data.mongodb.test.PersonWriteConverter());
}
@Bean
public LoggingEventListener<MongoMappingEvent> mappingEventsListener() {
return new LoggingEventListener<MongoMappingEvent>();
}
}-
The mapping base package defines the root path used to scan for entities used to pre initialize the
MappingContext. By default the configuration classes package is used. -
Configure additional custom converters for specific domain types that replace the default mapping procedure for those types with your custom implementation.
AbstractMongoClientConfiguration requires you to implement methods that define a com.mongodb.client.MongoClient as well as provide a database name. AbstractMongoClientConfiguration also has a method named getMappingBasePackage(…) that you can override to tell the converter where to scan for classes annotated with the @Document annotation.
You can add additional converters to the converter by overriding the customConversionsConfiguration method.
MongoDB’s native JSR-310 support can be enabled through MongoConverterConfigurationAdapter.useNativeDriverJavaTimeCodecs().
Also shown in the preceding example is a LoggingEventListener, which logs MongoMappingEvent instances that are posted onto Spring’s ApplicationContextEvent infrastructure.
|
Note
|
AbstractMongoClientConfiguration creates a MongoTemplate instance and registers it with the container under the name mongoTemplate.
|
Spring’s MongoDB namespace lets you enable mapping functionality in XML, as the following example shows:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mongo="http://www.springframework.org/schema/data/mongo"
xsi:schemaLocation="
http://www.springframework.org/schema/data/mongo https://www.springframework.org/schema/data/mongo/spring-mongo.xsd
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
<!-- Default bean name is 'mongo' -->
<mongo:mongo-client host="localhost" port="27017"/>
<mongo:db-factory dbname="database" mongo-ref="mongoClient"/>
<!-- by default look for a Mongo object named 'mongo' - default name used for the converter is 'mappingConverter' -->
<mongo:mapping-converter base-package="com.bigbank.domain">
<mongo:custom-converters>
<mongo:converter ref="readConverter"/>
<mongo:converter>
<bean class="org.springframework.data.mongodb.test.PersonWriteConverter"/>
</mongo:converter>
</mongo:custom-converters>
</mongo:mapping-converter>
<bean id="readConverter" class="org.springframework.data.mongodb.test.PersonReadConverter"/>
<!-- set the mapping converter to be used by the MongoTemplate -->
<bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate">
<constructor-arg name="mongoDbFactory" ref="mongoDbFactory"/>
<constructor-arg name="mongoConverter" ref="mappingConverter"/>
</bean>
<bean class="org.springframework.data.mongodb.core.mapping.event.LoggingEventListener"/>
</beans>The base-package property tells it where to scan for classes annotated with the @org.springframework.data.mongodb.core.mapping.Document annotation.
To take full advantage of the object mapping functionality inside the Spring Data MongoDB support, you should annotate your mapped objects with the @Document annotation.
Although it is not necessary for the mapping framework to have this annotation (your POJOs are mapped correctly, even without any annotations), it lets the classpath scanner find and pre-process your domain objects to extract the necessary metadata.
If you do not use this annotation, your application takes a slight performance hit the first time you store a domain object, because the mapping framework needs to build up its internal metadata model so that it knows about the properties of your domain object and how to persist them.
The following example shows a domain object:
package com.mycompany.domain;
@Document
public class Person {
@Id
private ObjectId id;
@Indexed
private Integer ssn;
private String firstName;
@Indexed
private String lastName;
}|
Important
|
The @Id annotation tells the mapper which property you want to use for the MongoDB _id property, and the @Indexed annotation tells the mapping framework to call createIndex(…) on that property of your document, making searches faster.
Automatic index creation is only done for types annotated with @Document.
|
|
Warning
|
Auto index creation is disabled by default and needs to be enabled through the configuration (see Index Creation). |
Spring Data MongoDB can automatically create indexes for entity types annotated with @Document.
Index creation must be explicitly enabled since version 3.0 to prevent undesired effects with collection lifecyle and performance impact.
Indexes are automatically created for the initial entity set on application startup and when accessing an entity type for the first time while the application runs.
We generally recommend explicit index creation for application-based control of indexes as Spring Data cannot automatically create indexes for collections that were recreated while the application was running.
IndexResolver provides an abstraction for programmatic index definition creation if you want to make use of @Indexed annotations such as @GeoSpatialIndexed, @TextIndexed, @CompoundIndex and @WildcardIndexed.
You can use index definitions with IndexOperations to create indexes.
A good point in time for index creation is on application startup, specifically after the application context was refreshed, triggered by observing ContextRefreshedEvent.
This event guarantees that the context is fully initialized.
Note that at this time other components, especially bean factories might have access to the MongoDB database.
|
Warning
|
===
Map like structures, unless annotated with @WildcardIndexed, are skipped by the IndexResolver because the map key, which cannot be resolved from static metadata, needs to be part of the index definition.
===
|
class MyListener {
@EventListener(ContextRefreshedEvent.class)
public void initIndicesAfterStartup() {
MappingContext<? extends MongoPersistentEntity<?>, MongoPersistentProperty> mappingContext = mongoTemplate
.getConverter().getMappingContext();
IndexResolver resolver = new MongoPersistentEntityIndexResolver(mappingContext);
IndexOperations indexOps = mongoTemplate.indexOps(DomainType.class);
resolver.resolveIndexFor(DomainType.class).forEach(indexOps::ensureIndex);
}
}class MyListener{
@EventListener(ContextRefreshedEvent.class)
public void initIndicesAfterStartup() {
MappingContext<? extends MongoPersistentEntity<?>, MongoPersistentProperty> mappingContext = mongoTemplate
.getConverter().getMappingContext();
// consider only entities that are annotated with @Document
mappingContext.getPersistentEntities()
.stream()
.filter(it -> it.isAnnotationPresent(Document.class))
.forEach(it -> {
IndexOperations indexOps = mongoTemplate.indexOps(it.getType());
resolver.resolveIndexFor(it.getType()).forEach(indexOps::ensureIndex);
});
}
}Alternatively, if you want to ensure index and collection presence before any component is able to access your database from your application, declare a @Bean method for MongoTemplate and include the code from above before returning the MongoTemplate object.
|
Note
|
To turn automatic index creation ON please override @Configuration
public class Config extends AbstractMongoClientConfiguration {
@Override
public boolean autoIndexCreation() {
return true;
}
// ...
} |
|
Important
|
Automatic index creation is turned OFF by default as of version 3.0. |
The MappingMongoConverter can use metadata to drive the mapping of objects to documents. The following annotations are available:
-
@Id: Applied at the field level to mark the field used for identity purpose. -
@MongoId: Applied at the field level to mark the field used for identity purpose. Accepts an optionalFieldTypeto customize id conversion. -
@Document: Applied at the class level to indicate this class is a candidate for mapping to the database. You can specify the name of the collection where the data will be stored. -
@DBRef: Applied at the field to indicate it is to be stored using a com.mongodb.DBRef. -
@DocumentReference: Applied at the field to indicate it is to be stored as a pointer to another document. This can be a single value (the id by default), or aDocumentprovided via a converter. -
@Indexed: Applied at the field level to describe how to index the field. -
@CompoundIndex(repeatable): Applied at the type level to declare Compound Indexes. -
@GeoSpatialIndexed: Applied at the field level to describe how to geoindex the field. -
@TextIndexed: Applied at the field level to mark the field to be included in the text index. -
@HashIndexed: Applied at the field level for usage within a hashed index to partition data across a sharded cluster. -
@Language: Applied at the field level to set the language override property for text index. -
@Transient: By default, all fields are mapped to the document. This annotation excludes the field where it is applied from being stored in the database. Transient properties cannot be used within a persistence constructor as the converter cannot materialize a value for the constructor argument. -
@PersistenceConstructor: Marks a given constructor - even a package protected one - to use when instantiating the object from the database. Constructor arguments are mapped by name to the key values in the retrieved Document. -
@Value: This annotation is part of the Spring Framework . Within the mapping framework it can be applied to constructor arguments. This lets you use a Spring Expression Language statement to transform a key’s value retrieved in the database before it is used to construct a domain object. In order to reference a property of a given document one has to use expressions like:@Value("#root.myProperty")whererootrefers to the root of the given document. -
@Field: Applied at the field level it allows to describe the name and type of the field as it will be represented in the MongoDB BSON document thus allowing the name and type to be different than the fieldname of the class as well as the property type. -
@Version: Applied at field level is used for optimistic locking and checked for modification on save operations. The initial value iszero(onefor primitive types) which is bumped automatically on every update.
The mapping metadata infrastructure is defined in a separate 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.
@Document
@CompoundIndex(name = "age_idx", def = "{'lastName': 1, 'age': -1}")
public class Person<T extends Address> {
@Id
private String id;
@Indexed(unique = true)
private Integer ssn;
@Field("fName")
private String firstName;
@Indexed
private String lastName;
private Integer age;
@Transient
private Integer accountTotal;
@DBRef
private List<Account> accounts;
private T address;
public Person(Integer ssn) {
this.ssn = ssn;
}
@PersistenceConstructor
public Person(Integer ssn, String firstName, String lastName, Integer age, T address) {
this.ssn = ssn;
this.firstName = firstName;
this.lastName = lastName;
this.age = age;
this.address = address;
}
public String getId() {
return id;
}
// no setter for Id. (getter is only exposed for some unit testing)
public Integer getSsn() {
return ssn;
}
// other getters/setters omitted
}|
Tip
|
public class Balance {
@Field(targetType = DECIMAL128)
private BigDecimal value;
// ...
}You may even consider your own, custom annotation. @Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
@Field(targetType = FieldType.DECIMAL128)
public @interface Decimal128 { }
// ...
public class Balance {
@Decimal128
private BigDecimal value;
// ...
} |
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:
-
If a parameter is annotated with the
@Valueannotation, the given expression is evaluated and the result is used as the parameter value. -
If the Java type has a property whose name matches the given field of the input document, then it’s property information is used to select the appropriate constructor parameter to pass the input field value to. This works only if the parameter name information is present in the java
.classfiles which can be achieved by compiling the source with debug information or using the new-parameterscommand-line switch for javac in Java 8. -
Otherwise a
MappingExceptionwill be thrown indicating that the given constructor parameter could not be bound.
class OrderItem {
private @Id String id;
private int quantity;
private double unitPrice;
OrderItem(String id, @Value("#root.qty ?: 0") int quantity, double unitPrice) {
this.id = id;
this.quantity = quantity;
this.unitPrice = unitPrice;
}
// getters/setters ommitted
}
Document input = new Document("id", "4711");
input.put("unitPrice", 2.5);
input.put("qty",5);
OrderItem item = converter.read(OrderItem.class, input);|
Note
|
The SpEL expression in the @Value annotation of the quantity parameter falls back to the value 0 if the given property path cannot be resolved.
|
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 individual properties.
|
Note
|
Compound indexes are very important to improve the performance of queries that involve criteria on multiple fields |
Here’s an example that creates a compound index of lastName in ascending order and age in descending order:
package com.mycompany.domain;
@Document
@CompoundIndex(name = "age_idx", def = "{'lastName': 1, 'age': -1}")
public class Person {
@Id
private ObjectId id;
private Integer age;
private String firstName;
private String lastName;
}|
Tip
|
@Document
@CompoundIndex(name = "cmp-idx-one", def = "{'firstname': 1, 'lastname': -1}")
@CompoundIndex(name = "cmp-idx-two", def = "{'address.city': -1, 'address.street': 1}")
public class Person {
String firstname;
String lastname;
Address address;
// ...
} |
Hashed indexes allow hash based sharding within a sharded cluster. Using hashed field values to shard collections results in a more random distribution. For details, refer to the MongoDB Documentation.
Here’s an example that creates a hashed index for _id:
@Document
public class DomainType {
@HashIndexed @Id String id;
// ...
}Hashed indexes can be created next to other index definitions like shown below, in that case both indices are created:
@Document
public class DomainType {
@Indexed
@HashIndexed
String value;
// ...
}In case the example above is too verbose, a compound annotation allows to reduce the number of annotations that need to be declared on a property:
@Document
public class DomainType {
@IndexAndHash(name = "idx...") (1)
String value;
// ...
}
@Indexed
@HashIndexed
@Retention(RetentionPolicy.RUNTIME)
public @interface IndexAndHash {
@AliasFor(annotation = Indexed.class, attribute = "name") (1)
String name() default "";
}-
Potentially register an alias for certain attributes of the meta annotation.
|
Note
|
Although index creation via annotations comes in handy for many scenarios cosider taking over more control by setting up indices manually via mongoOperations.indexOpsFor(Jedi.class)
.ensureIndex(HashedIndex.hashed("useTheForce")); |
A WildcardIndex is an index that can be used to include all fields or specific ones based a given (wildcard) pattern.
For details, refer to the MongoDB Documentation.
The index can be set up programmatically using WildcardIndex via IndexOperations.
mongoOperations
.indexOps(User.class)
.ensureIndex(new WildcardIndex("userMetadata"));db.user.createIndex({ "userMetadata.$**" : 1 }, {})The @WildcardIndex annotation allows a declarative index setup that can used either with a document type or property.
If placed on a type that is a root level domain entity (one annotated with @Document) , the index resolver will create a
wildcard index for it.
@Document
@WildcardIndexed
public class Product {
// …
}db.product.createIndex({ "$**" : 1 },{})The wildcardProjection can be used to specify keys to in-/exclude in the index.
wildcardProjection@Document
@WildcardIndexed(wildcardProjection = "{ 'userMetadata.age' : 0 }")
public class User {
private @Id String id;
private UserMetadata userMetadata;
}db.user.createIndex(
{ "$**" : 1 },
{ "wildcardProjection" :
{ "userMetadata.age" : 0 }
}
)Wildcard indexes can also be expressed by adding the annotation directly to the field.
Please note that wildcardProjection is not allowed on nested paths such as properties.
Projections on types annotated with @WildcardIndexed are omitted during index creation.
@Document
public class User {
private @Id String id;
@WildcardIndexed
private UserMetadata userMetadata;
}db.user.createIndex({ "userMetadata.$**" : 1 }, {})|
Note
|
The text index feature is disabled by default for MongoDB v.2.4. |
Creating a text index allows accumulating 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 the document score for ranking results.
The default language for the text index is English.To change the default language, set the language attribute to whichever language you want (for example,@Document(language="spanish")).
Using a property called language or @Language lets you define a language override on a per-document base.
The following example shows how to created a text index and set the language to Spanish:
@Document(language = "spanish")
class SomeEntity {
@TextIndexed String foo;
@Language String lang;
Nested nested;
}
class Nested {
@TextIndexed(weight=5) String bar;
String roo;
}Events are fired throughout the lifecycle of the mapping process. This is described in the Lifecycle Events section.
Declaring these beans in your Spring ApplicationContext causes them to be invoked whenever the event is dispatched.