Add value shortcut to Embedded.Nullable and Embedded.Empty for improved annotation usage. Move isEntity check into PersistentProperty.isEmbedded as both checks are issued always together.
Tweak documentation.
Original pull request: #173.
Embedded entities are used to design value objects in your Java domain model whose properties are flattened out into the table.
In the following example you see, that User.name is annotated with Embedded.
The consequence of this is that all properties of `UserName` are folded into the `user` table which consists of 3 columns (user_id, firstname, lastname).
Embedded entities may only contain simple property types. It is not possible to nest an embedded entity into another embedded one.
However, if the firstname and lastname column values are actually null within the result set, the entire property name will be set to null according to the onEmpty of Embedded, which nulls objects when all nested properties are null.
Opposite to this behaviour USE_EMPTY tries to create a new instance using either a default constructor or one that accepts nullable parameter values from the result set.
public class User {
@PrimaryKey("user_id")
private String userId;
@Embedded(onEmpty = USE_NULL)
UserName name;
}
public class UserName {
private String firstname;
private String lastname;
}
Original pull request: #173.
Remove FrozenIndicator from public API. Refactor to recursive type to reflect property type declaration nature. Rename to FrozenIndicator. Update documentation.
Original pull request: #172.
`@Frozen` is supported on UDTs, collection like properties (`Set`, `List` and `Map`), and their type parameters if those are UDTs.
For example
@Frozen Map<String, @Frozen MyUdt> propertyName;
Original pull request: #172.
We now use a configurable NamingStrategy to configure how table, user-defined type and column names are derived if the name is not expicitly configured. The default naming strategy uses the type/property name. Naming strategies allow customization with a transformation function (all lower-case/upper case, prepending/appending and more) and strategies can be provided by a custom implementation.
All DataType-resolution functionality is now encapsulated in ColumnTypeResolver and all DataType-related methods (getDataType(), getTupleType(), getUserType()) were migrated into ColumnTypeResolver. DataType resolution requires always a converter context to apply registered converters so this concern cannot be handled entirely on the mapping level.
Related to type resolution also schema object derivation (create table/index/user type) functionality was moved from CassandraMappingContext into SchemaFactory as schema object derivation requires the converter registrations.
We now resolve column types by using ColumnTypeResolver that encapsulates type lookups that previously were spread across different areas of the converter. We consistently apply type resolution for singular properties and collection/Map-like properties.
The `@Value` annotation can now be used on constructor parameters to evaluate expressions to obtain constructor values. The root object refers to a Row, UdtValue or TupleValue depending from which source the object gets materialized.
class WithValue {
final @Id String id;
final @Transient String firstname;
public WithValue(String id, @Value("#root.getString(1)") String firstname) {
this.id = id;
this.firstname = firstname;
}
}
