The meaning of embedding a Document in MongoDB is different compared to column based stores. Typically the term is used for a Document in Document approach and not for flattening out a values into the enclosing Document.
Closes: #3600
Original pull request: #3604.
pull/3611/head
Christoph Strobl5 years agocommitted byMark Paluch
@ -137,7 +137,7 @@ public class MongoPersistentEntityIndexResolver implements IndexResolver {
@@ -137,7 +137,7 @@ public class MongoPersistentEntityIndexResolver implements IndexResolver {
@ -187,7 +187,7 @@ public class MongoPersistentEntityIndexResolver implements IndexResolver {
@@ -187,7 +187,7 @@ public class MongoPersistentEntityIndexResolver implements IndexResolver {
@ -216,11 +216,11 @@ public class MongoPersistentEntityIndexResolver implements IndexResolver {
@@ -216,11 +216,11 @@ public class MongoPersistentEntityIndexResolver implements IndexResolver {
@ -133,10 +133,10 @@ public class MongoMappingContext extends AbstractMappingContext<MongoPersistentE
@@ -133,10 +133,10 @@ public class MongoMappingContext extends AbstractMappingContext<MongoPersistentE
@ -358,11 +358,11 @@ public class TypeBasedAggregationOperationContextUnitTests {
@@ -358,11 +358,11 @@ public class TypeBasedAggregationOperationContextUnitTests {
@ -370,11 +370,11 @@ public class TypeBasedAggregationOperationContextUnitTests {
@@ -370,11 +370,11 @@ public class TypeBasedAggregationOperationContextUnitTests {
@ -382,11 +382,11 @@ public class TypeBasedAggregationOperationContextUnitTests {
@@ -382,11 +382,11 @@ public class TypeBasedAggregationOperationContextUnitTests {
@ -394,64 +394,65 @@ public class TypeBasedAggregationOperationContextUnitTests {
@@ -394,64 +394,65 @@ public class TypeBasedAggregationOperationContextUnitTests {
@ -531,21 +532,21 @@ public class TypeBasedAggregationOperationContextUnitTests {
@@ -531,21 +532,21 @@ public class TypeBasedAggregationOperationContextUnitTests {
@ -1286,10 +1286,10 @@ public class MongoPersistentEntityIndexResolverUnitTests {
@@ -1286,10 +1286,10 @@ public class MongoPersistentEntityIndexResolverUnitTests {
@ -1301,10 +1301,10 @@ public class MongoPersistentEntityIndexResolverUnitTests {
@@ -1301,10 +1301,10 @@ public class MongoPersistentEntityIndexResolverUnitTests {
@ -1319,7 +1319,7 @@ public class MongoPersistentEntityIndexResolverUnitTests {
@@ -1319,7 +1319,7 @@ public class MongoPersistentEntityIndexResolverUnitTests {
@ -1514,30 +1514,30 @@ public class MongoPersistentEntityIndexResolverUnitTests {
@@ -1514,30 +1514,30 @@ public class MongoPersistentEntityIndexResolverUnitTests {
@ -1366,34 +1366,34 @@ public abstract class AbstractPersonRepositoryIntegrationTests {
@@ -1366,34 +1366,34 @@ public abstract class AbstractPersonRepositoryIntegrationTests {
@ -833,6 +833,6 @@ Events are fired throughout the lifecycle of the mapping process. This is descri
@@ -833,6 +833,6 @@ Events are fired throughout the lifecycle of the mapping process. This is descri
Declaring these beans in your Spring ApplicationContext causes them to be invoked whenever the event is dispatched.
Embedded entities are used to design value objects in your Java domain model whose properties are flattened out into the parent's MongoDB Document.
Unwrapped entities are used to design value objects in your Java domain model whose properties are flattened out into the parent's MongoDB Document.
[[embedded-entities.mapping]]
=== Embedded Types Mapping
[[unwrapped-entities.mapping]]
=== Unwrapped Types Mapping
Consider the following domain model where `User.name` is annotated with `@Embedded`.
The `@Embedded` annotation signals that all properties of `UserName` should be unwrapped into the `user` document that owns the `name` property.
Consider the following domain model where `User.name` is annotated with `@Unwrapped`.
The `@Unwrapped` annotation signals that all properties of `UserName` should be flattened out into the `user` document that owns the `name` property.
.Sample Code of embedding objects
.Sample Code of unwrapping objects
====
[source,java]
----
@ -18,7 +18,7 @@ class User {
@@ -18,7 +18,7 @@ class User {
@Id
String userId;
@Embedded(onEmpty = USE_NULL) <1>
@Unwrapped(onEmpty = USE_NULL) <1>
UserName name;
}
@ -43,23 +43,23 @@ class UserName {
@@ -43,23 +43,23 @@ class UserName {
By using `onEmpty=USE_EMPTY` an empty `UserName`, with potential `null` value for its properties, will be created.
====
For less verbose embeddable type declarations use `@Embedded.Nullable` and `@Embedded.Empty` instead `@Embedded(onEmpty = USE_NULL)` and `@Embedded(onEmpty = USE_EMPTY)`.
For less verbose embeddable type declarations use `@Unwrapped.Nullable` and `@Unwrapped.Empty` instead `@Unwrapped(onEmpty = USE_NULL)` and `@Unwrapped(onEmpty = USE_EMPTY)`.
Both annotations are meta-annotated with JSR-305 `@javax.annotation.Nonnull` to aid with nullability inspections.
[WARNING]
====
It is possible to use complex types within an embedded object.
However, those must not be, nor contain embedded fields themselves.
It is possible to use complex types within an unwrapped object.
However, those must not be, nor contain unwrapped fields themselves.
====
[[embedded-entities.mapping.field-names]]
=== Embedded Types field names
[[unwrapped-entities.mapping.field-names]]
=== Unwrapped Types field names
A value object can be embedded multiple times by using the optional `prefix` attribute of the `@Embedded` annotation.
By dosing so the chosen prefix is prepended to each property or `@Field("…")` name in the embedded object.
A value object can be unwrapped multiple times by using the optional `prefix` attribute of the `@Unwrapped` annotation.
By dosing so the chosen prefix is prepended to each property or `@Field("…")` name in the unwrapped object.
Please note that values will overwrite each other if multiple properties render to the same field name.
.Sample Code of embedded object with name prefix
.Sample Code of unwrapped object with name prefix
====
[source,java]
----
@ -68,10 +68,10 @@ class User {
@@ -68,10 +68,10 @@ class User {
@Id
String userId;
@Embedded.Nullable(prefix = "u_") <1>
@Unwrapped.Nullable(prefix = "u_") <1>
UserName name;
@Embedded.Nullable(prefix = "a_") <2>
@Unwrapped.Nullable(prefix = "a_") <2>
UserName name;
}
@ -97,10 +97,10 @@ class UserName {
@@ -97,10 +97,10 @@ class UserName {
<2> All properties of `UserName` are prefixed with `a_`.
====
While combining the `@Field` annotation with `@Embedded` on the very same property does not make sense and therefore leads to an error.
It is a totally valid approach to use `@Field` on any of the embedded types properties.
While combining the `@Field` annotation with `@Unwrapped` on the very same property does not make sense and therefore leads to an error.
It is a totally valid approach to use `@Field` on any of the unwrapped types properties.
.Sample Code embedded object with `@Field` annotation
.Sample Code unwrapping objects with `@Field` annotation
====
[source,java]
----
@ -109,7 +109,7 @@ public class User {
@@ -109,7 +109,7 @@ public class User {
@Id
private String userId;
@Embedded.Nullable(prefix = "u-") <1>
@Unwrapped.Nullable(prefix = "u-") <1>
UserName name;
}
@ -132,17 +132,17 @@ public class UserName {
@@ -132,17 +132,17 @@ public class UserName {
}
----
<1> All properties of `UserName` are prefixed with `u-`.
<2> Final field names are a result of concatenating `@Embedded(prefix)` and `@Field(name)`.
<2> Final field names are a result of concatenating `@Unwrapped(prefix)` and `@Field(name)`.
====
[[embedded-entities.queries]]
=== Query on Embedded Objects
[[unwrapped-entities.queries]]
=== Query on Unwrapped Objects
Defining queries on embedded properties is possible on type- as well as field-level as the provided `Criteria` is matched against the domain type.
Defining queries on unwrapped properties is possible on type- as well as field-level as the provided `Criteria` is matched against the domain type.
Prefixes and potential custom field names will be considered when rendering the actual query.
Use the property name of the embedded object to match against all contained fields as shown in the sample below.
Use the property name of the unwrapped object to match against all contained fields as shown in the sample below.
Though possible, using the embedded object itself as sort criteria includes all of its fields in unpredictable order and may result in inaccurate ordering.
Though possible, using the unwrapped object itself as sort criteria includes all of its fields in unpredictable order and may result in inaccurate ordering.
====
[[embedded-entities.queries.project]]
==== Field projection on embedded objects
[[unwrapped-entities.queries.project]]
==== Field projection on unwrapped objects
Fields of embedded objects can be subject for projection either as a whole or via single fields as shown in the samples below.
Fields of unwrapped objects can be subject for projection either as a whole or via single fields as shown in the samples below.