Update entity linking support to derive document pointer from lookup query.
Simplify usage by computing the pointer from the lookup.
Update the reference documentation, add JavaDoc and refine API.
Original pull request: #3647.
Closes#3602.
pull/3662/head
Christoph Strobl5 years agocommitted byMark Paluch
@ -117,7 +117,8 @@ public class DefaultDbRefResolver extends DefaultReferenceResolver implements Db
@@ -117,7 +117,8 @@ public class DefaultDbRefResolver extends DefaultReferenceResolver implements Db
@ -157,9 +158,9 @@ public class DefaultDbRefResolver extends DefaultReferenceResolver implements Db
@@ -157,9 +158,9 @@ public class DefaultDbRefResolver extends DefaultReferenceResolver implements Db
@ -498,9 +499,9 @@ public class DefaultDbRefResolver extends DefaultReferenceResolver implements Db
@@ -498,9 +499,9 @@ public class DefaultDbRefResolver extends DefaultReferenceResolver implements Db
@ -49,7 +43,7 @@ public class DefaultReferenceLoader implements ReferenceLoader {
@@ -49,7 +43,7 @@ public class DefaultReferenceLoader implements ReferenceLoader {
@ -63,9 +57,9 @@ public class DefaultReferenceLoader implements ReferenceLoader {
@@ -63,9 +57,9 @@ public class DefaultReferenceLoader implements ReferenceLoader {
@ -44,24 +38,26 @@ public class DefaultReferenceResolver implements ReferenceResolver {
@@ -44,24 +38,26 @@ public class DefaultReferenceResolver implements ReferenceResolver {
@ -231,6 +231,15 @@ public class BasicMongoPersistentProperty extends AnnotationBasedPersistentPrope
@@ -231,6 +231,15 @@ public class BasicMongoPersistentProperty extends AnnotationBasedPersistentPrope
@ -240,6 +249,16 @@ public class BasicMongoPersistentProperty extends AnnotationBasedPersistentPrope
@@ -240,6 +249,16 @@ public class BasicMongoPersistentProperty extends AnnotationBasedPersistentPrope
@ -1434,4 +1434,19 @@ public abstract class AbstractPersonRepositoryIntegrationTests {
@@ -1434,4 +1434,19 @@ public abstract class AbstractPersonRepositoryIntegrationTests {
@ -480,6 +480,7 @@ The MappingMongoConverter can use metadata to drive the mapping of objects to do
@@ -480,6 +480,7 @@ The MappingMongoConverter can use metadata to drive the mapping of objects to do
* `@MongoId`: Applied at the field level to mark the field used for identity purpose. Accepts an optional `FieldType` to 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 a `Document` provided 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.
@ -826,6 +827,370 @@ Required properties that are also defined as lazy loading ``DBRef`` and used as
@@ -826,6 +827,370 @@ Required properties that are also defined as lazy loading ``DBRef`` and used as
TIP: Lazily loaded ``DBRef``s can be hard to debug. Make sure tooling does not accidentally trigger proxy resolution by eg. calling `toString()` or some inline debug rendering invoking property getters.
Please consider to enable _trace_ logging for `org.springframework.data.mongodb.core.convert.DefaultDbRefResolver` to gain insight on `DBRef` resolution.
[[mapping-usage.linking]]
=== Using Document References
Using `@DocumentReference` offers an alternative way of linking entities in MongoDB.
While the goal is the same as when using <<mapping-usage-references,DBRefs>>, the store representation is different.
`DBRef` resolves to a document with a fixed structure as outlined in the https://docs.mongodb.com/manual/reference/database-references/[MongoDB Reference documentation]. +
Document references, do not follow a specific format.
They can be literally anything, a single value, an entire document, basically everything that can be stored in MongoDB.
By default, the mapping layer will use the referenced entities _id_ value for storage and retrieval, like in the sample below.
<1> Mark the collection of `Account` values to be linked.
<2> The mapping framework does not handle cascading saves, so make sure to persist the referenced entity individually.
<3> Add the reference to the existing entity.
<4> Linked `Account` entities are represented as an array of their `_id` values.
====
The sample above uses an `_id` based fetch query (`{ '_id' : ?#{#target} }`) for data retrieval and resolves linked entities eagerly.
It is possible to alter resolution defaults (listed below) via the attributes of `@DocumentReference`
.@DocumentReference defaults
[cols="2,3,5", options="header"]
|===
| Attribute | Description | Default
| `db`
| The target database name for collection lookup.
| The configured database provided by `MongoDatabaseFactory.getMongoDatabase()`.
| `collection`
| The target collection name.
| The annotated properties domain type, respectively the value type in case of `Collection` like or `Map` properties, collection name.
| `lookup`
| The single document lookup query evaluating placeholders via SpEL expressions using `#target` as the marker for a given source value. `Collection` like or `Map` properties combine individual lookups via an `$or` operator.
| An `_id` field based query (`{ '_id' : ?#{#target} }`) using the loaded source value.
| `lazy`
| If set to `true` value resolution is delayed upon first access of the property.
| Resolves properties eagerly by default.
|===
`@DocumentReference(lookup=...)` allows to define custom queries that are independent from the `_id` field and therefore offer a flexible way of defining links between entities as demonstrated in the sample below, where the `Publisher` of a book is referenced by its acronym instead of the internal `id`.
<1> Use the `acronym` field to query for entities in the `Publisher` collection.
<2> Lazy load back references to the `Book` collection.
====
The above snipped shows the reading side of things when working with custom linked objects.
To make the writing part aware of the modified document pointer a custom converter, capable of the transformation into a `DocumentPointer`, like the one below, needs to be registered.
====
[source,java]
----
@WritingConverter
class PublisherReferenceConverter implements Converter<Publisher, DocumentPointer<String>> {
@Override
public DocumentPointer<String> convert(Publisher source) {
return () -> source.getAcronym();
}
}
----
====
If no `DocumentPointer` converter is provided the target linkage document can be computed based on the given lookup query.
In this case the association target properties are evaluated as shown in the following sample.