此版本仍在开发中,尚不被认为是稳定的。对于最新的稳定版本,请使用 Spring Data Couchbase 5.5.2! |
建模实体
本章介绍如何对实体进行建模,并解释它们在 Couchbase Server 本身中的对应表示。
对象映射基础知识
本节介绍 Spring Data 对象映射、对象创建、字段和属性访问、可变性和不变性的基础知识。请注意,本节仅适用于不使用底层数据存储(如 JPA)的对象映射的 Spring Data 模块。此外,请务必查阅特定于存储的部分,了解特定于存储的对象映射,例如索引、自定义列或字段名称等。
Spring Data 对象映射的核心职责是创建域对象的实例并将存储原生数据结构映射到这些实例上。这意味着我们需要两个基本步骤:
-
使用公开的构造函数之一创建实例。
-
实例填充以具体化所有公开的属性。
对象创建
Spring Data 自动尝试检测持久实体的构造函数,以用于具体化该类型的对象。解析算法的工作原理如下:
-
如果有一个静态工厂方法用
@PersistenceCreator
然后它被使用。 -
如果存在单个构造函数,则使用它。
-
如果有多个构造函数,并且只有一个构造函数被
@PersistenceCreator
,它被使用。 -
如果类型是 Java
Record
使用规范构造函数。 -
如果存在无参数构造函数,则使用它。其他构造函数将被忽略。
值解析假定构造函数/工厂方法参数名称与实体的属性名称匹配,即执行解析时,就像要填充属性一样,包括映射中的所有自定义(不同的数据存储列或字段名称等)。这还需要类文件中可用的参数名称信息或@ConstructorProperties
注释存在于构造函数上。
可以使用 Spring Framework 的@Value
使用特定于存储的 SpEL 表达式进行值注释。有关更多详细信息,请参阅有关特定于存储的映射部分。
财产人口
创建实体的实例后,Spring Data 将填充该类的所有剩余持久属性。 除非实体的构造函数已经填充(即通过其构造函数参数列表使用),否则将首先填充标识符属性以允许解析循环对象引用。 之后,构造函数尚未填充的所有非瞬态属性都将在实体实例上设置。 为此,我们使用以下算法:
-
如果该属性是不可变的,但公开了
with…
方法(见下文),我们使用with…
方法,以创建具有新属性值的新实体实例。 -
如果定义了属性访问(即通过 getter 和 setter 访问),我们将调用 setter 方法。
-
如果属性是可变的,我们直接设置字段。
-
如果该属性是不可变的,我们将使用持久化作(请参阅对象创建)使用的构造函数来创建实例的副本。
-
默认情况下,我们直接设置字段值。
让我们看一下以下实体:
class Person {
private final @Id Long id; (1)
private final String firstname, lastname; (2)
private final LocalDate birthday;
private final int age; (3)
private String comment; (4)
private @AccessType(Type.PROPERTY) String remarks; (5)
static Person of(String firstname, String lastname, LocalDate birthday) { (6)
return new Person(null, firstname, lastname, birthday,
Period.between(birthday, LocalDate.now()).getYears());
}
Person(Long id, String firstname, String lastname, LocalDate birthday, int age) { (6)
this.id = id;
this.firstname = firstname;
this.lastname = lastname;
this.birthday = birthday;
this.age = age;
}
Person withId(Long id) { (1)
return new Person(id, this.firstname, this.lastname, this.birthday, this.age);
}
void setRemarks(String remarks) { (5)
this.remarks = remarks;
}
}
1 | identifier 属性是 final ,但设置为null 在构造函数中。
该类公开了withId(…) 用于设置标识符的方法,例如,当实例插入到数据存储中并生成标识符时。
原件Person 实例在创建新实例时保持不变。
相同的模式通常适用于存储管理的其他属性,但可能需要更改才能进行持久性作。
wither 方法是可选的,因为持久性构造函数(见 6)实际上是一个复制构造函数,并且设置该属性将转换为创建一个应用了新标识符值的新实例。 |
2 | 这firstname 和lastname 属性是可能通过 getter 公开的普通不可变属性。 |
3 | 这age 属性是不可变的,但派生自birthday 财产。
在所示设计中,数据库值将胜过默认值,因为 Spring Data 使用唯一声明的构造函数。
即使意图是应首选计算,此构造函数也必须采用age as 参数(可能会忽略它),否则属性填充步骤将尝试设置 age 字段,但由于它是不可变的并且没有with… 方法存在。 |
4 | 这comment 属性是可变的,通过直接设置其字段来填充。 |
5 | 这remarks 属性是可变的,并通过调用 setter 方法填充。 |
6 | 该类公开了用于创建对象的工厂方法和构造函数。
这里的核心思想是使用工厂方法而不是额外的构造函数,以避免需要通过@PersistenceCreator .
相反,属性的默认值是在工厂方法中处理的。
如果您希望 Spring Data 使用工厂方法进行对象实例化,请使用@PersistenceCreator . |
一般建议
-
尝试坚持使用不可变对象 — 不可变对象很容易创建,因为具体化对象只需调用其构造函数即可。 此外,这还可以避免域对象中充斥着允许客户端代码作对象状态的 setter 方法。 如果需要这些,请更喜欢将它们设置为包保护,以便它们只能由有限数量的共置类型调用。 仅构造函数的具体化比属性填充快 30%。
-
提供全参数构造函数 — 即使不能或不想将实体建模为不可变值,提供将实体的所有属性(包括可变属性)作为参数的构造函数仍然有价值,因为这允许对象映射跳过属性填充以获得最佳性能。
-
使用工厂方法而不是重载的构造函数来避免
@PersistenceCreator
— 对于最佳性能所需的全参数构造函数,我们通常希望公开更多特定于应用程序用例的构造函数,这些构造函数省略了自动生成的标识符等内容。 使用静态工厂方法来公开全参数构造函数的这些变体是一种既定模式。 -
确保遵守允许使用生成的实例化器和属性访问器类的约束 —
-
对于要生成的标识符,仍将最终字段与全参数持久性构造函数(首选)或
with…
方法— -
使用 Lombok 避免样板代码 — 由于持久化作通常需要构造函数接受所有参数,因此它们的声明变成了样板参数对字段赋值的繁琐重复,最好通过使用 Lombok 的
@AllArgsConstructor
.
覆盖属性
Java 允许灵活地设计域类,其中子类可以定义已在其超类中声明的相同名称的属性。 请考虑以下示例:
public class SuperType {
private CharSequence field;
public SuperType(CharSequence field) {
this.field = field;
}
public CharSequence getField() {
return this.field;
}
public void setField(CharSequence field) {
this.field = field;
}
}
public class SubType extends SuperType {
private String field;
public SubType(String field) {
super(field);
this.field = field;
}
@Override
public String getField() {
return this.field;
}
public void setField(String field) {
this.field = field;
// optional
super.setField(field);
}
}
这两个类都定义了一个field
使用可分配类型。SubType
然而阴影SuperType.field
.
根据类设计,使用构造函数可能是唯一的默认方法SuperType.field
.
或者,调用super.setField(…)
在 setter 中可以设置field
在SuperType
.
所有这些机制都会在某种程度上产生冲突,因为属性共享相同的名称,但可能表示两个不同的值。
如果类型不可分配,Spring Data 会跳过超类型属性。
也就是说,被覆盖属性的类型必须可分配给其超类型属性类型才能注册为覆盖,否则超类型属性将被视为暂时性。
我们通常建议使用不同的属性名称。
Spring Data 模块通常支持持有不同值的覆盖属性。 从编程模型的角度来看,有几件事需要考虑:
-
应该保留哪个属性(默认为所有声明的属性)? 您可以通过使用
@Transient
. -
如何在数据存储中表示属性? 对不同的值使用相同的字段/列名称通常会导致数据损坏,因此您应该使用显式字段/列名称对至少一个属性进行注释。
-
用
@AccessType(PROPERTY)
不能使用,因为如果不对 setter 实现做出任何进一步的假设,就不能通常设置超属性。
Kotlin 支持
Spring Data 调整了 Kotlin 的细节以允许对象创建和变更。
Kotlin 对象创建
支持实例化 Kotlin 类,默认情况下所有类都是不可变的,并且需要显式属性声明来定义可变属性。
Spring Data 自动尝试检测持久实体的构造函数,以用于具体化该类型的对象。解析算法的工作原理如下:
-
如果有一个构造函数用
@PersistenceCreator
,它被使用。 -
如果类型是 Kotlin 数据类,则使用主构造函数。
-
如果有一个静态工厂方法用
@PersistenceCreator
然后它被使用。 -
如果存在单个构造函数,则使用它。
-
如果有多个构造函数,并且只有一个构造函数被
@PersistenceCreator
,它被使用。 -
如果类型是 Java
Record
使用规范构造函数。 -
如果存在无参数构造函数,则使用它。其他构造函数将被忽略。
考虑以下几点data
类Person
:
data class Person(val id: String, val name: String)
上面的类编译为具有显式构造函数的典型类。我们可以通过添加另一个构造函数来自定义此类,并使用@PersistenceCreator
要指示构造函数首选项:
data class Person(var id: String, val name: String) {
@PersistenceCreator
constructor(id: String) : this(id, "unknown")
}
Kotlin 支持参数可选性,允许在未提供参数的情况下使用默认值。
当 Spring Data 检测到具有参数默认值的构造函数时,如果数据存储不提供值(或只是返回null
),以便 Kotlin 可以应用参数默认设置。考虑以下类,该类将参数默认值应用于name
data class Person(var id: String, val name: String = "unknown")
每次name
参数不是结果的一部分,或者其值是null
,则name
默认为unknown
.
Spring Data 不支持委托属性。映射元数据过滤 Kotlin 数据类的委托属性。
在所有其他情况下,您可以通过使用@Transient . |
Kotlin 数据类的属性填充
在 Kotlin 中,默认情况下所有类都是不可变的,并且需要显式属性声明来定义可变属性。
考虑以下几点data
类Person
:
data class Person(val id: String, val name: String)
该类实际上是不可变的。
它允许在 Kotlin 生成copy(…)
创建新对象实例的方法,从现有对象复制所有属性值,并将作为参数提供的属性值应用于该方法。
Kotlin 覆盖属性
Kotlin 允许声明属性覆盖来更改子类中的属性。
open class SuperType(open var field: Int)
class SubType(override var field: Int = 1) :
SuperType(field) {
}
这样的排列呈现两个属性,名称为field
. Kotlin 为每个类中的每个属性生成属性访问器(getter 和 setter)。实际上,代码如下所示:
public class SuperType {
private int field;
public SuperType(int field) {
this.field = field;
}
public int getField() {
return this.field;
}
public void setField(int field) {
this.field = field;
}
}
public final class SubType extends SuperType {
private int field;
public SubType(int field) {
super(field);
this.field = field;
}
public int getField() {
return this.field;
}
public void setField(int field) {
this.field = field;
}
}
getter 和 setter onSubType
仅设置SubType.field
而不是SuperType.field
. 在这样的安排中,使用构造函数是将SuperType.field
. 将方法添加到SubType
设置SuperType.field
通过this.SuperType.field = …
是可能的,但不符合受支持的约定。属性替代在某种程度上会产生冲突,因为属性共享相同的名称,但可能表示两个不同的值。我们通常建议使用不同的属性名称。
Spring Data 模块通常支持持有不同值的覆盖属性。 从编程模型的角度来看,有几件事需要考虑:
-
应该保留哪个属性(默认为所有声明的属性)? 您可以通过使用
@Transient
. -
如何在数据存储中表示属性? 对不同的值使用相同的字段/列名称通常会导致数据损坏,因此您应该使用显式字段/列名称对至少一个属性进行注释。
-
用
@AccessType(PROPERTY)
不能使用,因为无法设置超级属性。
Kotlin 值类
Kotlin 值类专为更具表现力的领域模型而设计,以使底层概念显式化。 Spring Data 可以读取和写入使用值类定义属性的类型。
考虑以下域模型:
@JvmInline
value class EmailAddress(val theAddress: String) (1)
data class Contact(val id: String, val name:String, val emailAddress: EmailAddress) (2)
1 | 具有不可为 null 值类型的简单值类。 |
2 | 使用EmailAddress value 类。 |
使用非基元值类型的不可为 null 属性在编译类中平展为值类型。 可为 null 的基元值类型或可为 null 的值中值类型使用其包装器类型表示,这会影响值类型在数据库中的表示方式。 |
文档和字段
所有实体都应使用@Document
注释,但这不是必需的。
此外,实体中的每个字段都应使用@Field
注解。虽然这 - 严格来说 -
可选,它有助于减少边缘情况并清楚地显示实体的意图和设计。它也可以用于
将字段存储在其他名称下。
还有一个特别的@Id
注释,这需要始终到位。最佳做法是同时命名属性id
.
这里有一个非常简单的User
实体:
import org.springframework.data.annotation.Id;
import org.springframework.data.couchbase.core.mapping.Field;
import org.springframework.data.couchbase.core.mapping.Document;
@Document
public class User {
@Id
private String id;
@Field
private String firstname;
@Field
private String lastname;
public User(String id, String firstname, String lastname) {
this.id = id;
this.firstname = firstname;
this.lastname = lastname;
}
public String getId() {
return id;
}
public String getFirstname() {
return firstname;
}
public String getLastname() {
return lastname;
}
}
Couchbase Server 支持文档的自动过期。
该库通过@Document
注解。
您可以设置一个expiry
值,该值转换为文档被自动删除之前的秒数。
如果要让它在突变后 10 秒内过期,请将其设置为@Document(expiry = 10)
.
或者,您可以使用 Spring 的属性支持和expiryExpression
参数,以允许动态更改到期值。
例如:@Document(expiryExpression = "${valid.document.expiry}")
.
该属性必须可解析为 int 值,并且这两种方法不能混合使用。
如果希望文档中的字段名称与实体中使用的字段名称不同,则可以在@Field
注解。
例如,如果您想保持文档较小,您可以将 firstname 字段设置为@Field("fname")
.
在 JSON 文档中,你将看到{"fname": ".."}
而不是{"firstname": ".."}
.
这@Id
注释需要存在,因为 Couchbase 中的每个文档都需要一个唯一的键。
此键需要是长度最多为 250 个字符的任何字符串。
随意使用适合您的用例的任何内容,无论是 UUID、电子邮件地址还是其他任何内容。
可以选择为对 Couchbase-Server 存储桶的写入分配持久性要求;指示 Couchbase Server 在集群中内存和/或磁盘位置的多个节点上更新指定的文档;在考虑要提交的写入之前。
默认持久性要求也可以通过@Document
或@Durability
附注。
例如:@Document(durabilityLevel = DurabilityLevel.MAJORITY)
将强制将突变复制到大多数数据服务节点。这两个注释都支持基于表达式的持久性级别分配,方法是durabilityExpression
属性(注意 SPEL 不支持)。
数据类型和转换器
选择的存储格式是 JSON。它很棒,但像许多数据表示一样,它允许的数据类型比您直接在 Java 中表达的数据类型要少。 因此,对于所有非原始类型,需要进行某种形式的与受支持类型的转换。
对于以下实体字段类型,无需添加特殊处理:
Java 类型 | JSON 表示 |
---|---|
字符串 |
字符串 |
布尔 |
布尔 |
字节 |
数 |
短 |
数 |
整数 |
数 |
长 |
数 |
浮 |
数 |
双 |
数 |
零 |
写入时忽略 |
由于 JSON 支持对象(“映射”)和列表,Map
和List
类型可以自然转换。
如果它们仅包含上一段中的基元字段类型,则也不需要添加特殊处理。
这是一个例子:
@Document
public class User {
@Id
private String id;
@Field
private List<String> firstnames;
@Field
private Map<String, Integer> childrenAges;
public User(String id, List<String> firstnames, Map<String, Integer> childrenAges) {
this.id = id;
this.firstnames = firstnames;
this.childrenAges = childrenAges;
}
}
使用一些示例数据存储用户可能如下所示为 JSON 表示形式:
{
"_class": "foo.User",
"childrenAges": {
"Alice": 10,
"Bob": 5
},
"firstnames": [
"Foo",
"Bar",
"Baz"
]
}
您不需要一直将所有内容分解为原始类型和列表/映射。
当然,您也可以用这些原始值组合其他对象。
让我们修改最后一个示例,以便我们想要存储一个List
之Children
:
@Document
public class User {
@Id
private String id;
@Field
private List<String> firstnames;
@Field
private List<Child> children;
public User(String id, List<String> firstnames, List<Child> children) {
this.id = id;
this.firstnames = firstnames;
this.children = children;
}
static class Child {
private String name;
private int age;
Child(String name, int age) {
this.name = name;
this.age = age;
}
}
}
填充的对象可以如下所示:
{
"_class": "foo.User",
"children": [
{
"age": 4,
"name": "Alice"
},
{
"age": 3,
"name": "Bob"
}
],
"firstnames": [
"Foo",
"Bar",
"Baz"
]
}
大多数时候,您还需要存储一个时间值,例如Date
.
由于它不能直接存储在 JSON 中,因此需要进行转换。
该库实现了Date
,Calendar
和 JodaTime 类型(如果在类路径上)。
默认情况下,所有这些在文档中都表示为 unix 时间戳(数字)。
您始终可以使用自定义转换器覆盖默认行为,如下所示。
这是一个例子:
@Document
public class BlogPost {
@Id
private String id;
@Field
private Date created;
@Field
private Calendar updated;
@Field
private String title;
public BlogPost(String id, Date created, Calendar updated, String title) {
this.id = id;
this.created = created;
this.updated = updated;
this.title = title;
}
}
填充的对象可以如下所示:
{
"title": "a blog post title",
"_class": "foo.BlogPost",
"updated": 1394610843,
"created": 1394610843897
}
或者,可以通过设置系统属性将日期与符合 ISO-8601 的字符串进行转换。org.springframework.data.couchbase.useISOStringConverterForDate
设置为 true。如果您想覆盖转换器或实现自己的转换器,这也是可能的。该库实现了通用的 Spring Converter 模式。您可以在配置中的 bean 创建时插入自定义转换器。以下是配置它的方法(在覆盖的AbstractCouchbaseConfiguration
):
@Override
public CustomConversions customConversions() {
return new CustomConversions(Arrays.asList(FooToBarConverter.INSTANCE, BarToFooConverter.INSTANCE));
}
@WritingConverter
public static enum FooToBarConverter implements Converter<Foo, Bar> {
INSTANCE;
@Override
public Bar convert(Foo source) {
return /* do your conversion here */;
}
}
@ReadingConverter
public static enum BarToFooConverter implements Converter<Bar, Foo> {
INSTANCE;
@Override
public Foo convert(Bar source) {
return /* do your conversion here */;
}
}
在进行自定义转化时,需要注意以下几点:
-
为了使其明确,请始终使用
@WritingConverter
和@ReadingConverter
转换器上的注释。 特别是如果您正在处理原始类型转换,这将有助于减少可能的错误转换。 -
如果您实现了写入转换器,请确保仅解码为原始类型、映射和列表。 如果您需要更复杂的对象类型,请使用
CouchbaseDocument
和CouchbaseList
类型,底层翻译引擎也可以理解这些类型。 最好的选择是坚持尽可能简单的转换。 -
始终将更多特殊转换器放在通用转换器之前,以避免执行错误转换器的情况。
-
对于日期,读取转换器应该能够从任何
Number
(不仅仅是Long
). 这是 N1QL 支持所必需的。
乐观锁定
在某些情况下,您可能希望确保在对文档执行变更作时不会覆盖其他用户更改。为此,您有三个选择:事务(自 Couchbase 6.5 起)、悲观并发(锁定)或乐观并发。
乐观并发往往提供比悲观并发或事务更好的性能,因为数据上没有实际的锁,也不会存储有关作的额外信息(没有事务日志)。
为了实现乐观锁定,Couchbase 使用 CAS(比较和交换)方法。当文档发生变化时,CAS 值也会发生变化。 CAS 对客户端是不透明的,您唯一需要知道的是,当内容或元信息也发生变化时,它也会发生变化。
在其他数据存储中,可以通过带有递增计数器的任意版本字段来实现类似的行为。由于 Couchbase 以更好的方式支持这一点,因此很容易实现。如果您想要自动乐观锁定支持,您需要做的就是添加一个@Version
像这样长字段上的注释:
@Document
public class User {
@Version
private long version;
// constructor, getters, setters...
}
如果您通过模板或存储库加载文档,版本字段将自动填充当前 CAS 值。请务必注意,您不应访问该字段,甚至不应自行更改它。保存回文档后,它将成功或失败,并显示OptimisticLockingFailureException
. 如果您遇到这样的异常,则进一步的方法取决于您想要在应用程序方面实现的目标。您应该重试完整的加载-更新-写入周期,或者将错误传播到上层以进行正确处理。
验证
该库支持 JSR 303 验证,它直接基于实体中的注释。当然,您可以在服务层中添加各种验证,但这样它就可以很好地与实际实体耦合。
要使其正常工作,您需要包含两个额外的依赖项。JSR 303 和实现它的库,例如 hibernate 支持的库:
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
</dependency>
现在您需要在配置中添加两个 bean:
@Bean
public LocalValidatorFactoryBean validator() {
return new LocalValidatorFactoryBean();
}
@Bean
public ValidatingCouchbaseEventListener validationEventListener() {
return new ValidatingCouchbaseEventListener(validator());
}
现在,您可以使用 JSR303 注释来注释字段。如果验证save()
失败,则ConstraintViolationException
被抛出。
@Size(min = 10)
@Field
private String name;
审计
可以通过 Spring Data 审计机制自动审计实体(跟踪哪个用户创建了对象、更新对象以及在什么时间)。
首先,请注意,只有具有@Version
可以审核带注释的字段以进行创建(否则框架会将创建解释为更新)。
审核的工作原理是使用@CreatedBy
,@CreatedDate
,@LastModifiedBy
和@LastModifiedDate
. 在持久化实体时,框架将自动在这些字段上注入正确的值。xxxDate 注释必须放在Date
字段(或兼容,例如 jodatime 类),而 xxxBy 注释可以放在任何类的字段上T
(尽管两个字段必须是同一类型)。
要配置审计,首先您需要在上下文中有一个审计员感知 bean。所述 bean 必须是AuditorAware<T>
(允许生成一个可以存储在 xxxBy 类型的 xxxBy 字段中的值T
我们之前看到)。其次,您必须在@Configuration
类,使用@EnableCouchbaseAuditing
注解。
这是一个例子:
@Document
public class AuditedItem {
@Id
private final String id;
private String value;
@CreatedBy
private String creator;
@LastModifiedBy
private String lastModifiedBy;
@LastModifiedDate
private Date lastModification;
@CreatedDate
private Date creationDate;
@Version
private long version;
//..omitted constructor/getters/setters/...
}
注意两者@CreatedBy
和@LastModifiedBy
都放在一个String
字段,所以我们的AuditorAware
必须与String
.
public class NaiveAuditorAware implements AuditorAware<String> {
private String auditor = "auditor";
@Override
public String getCurrentAuditor() {
return auditor;
}
public void setAuditor(String auditor) {
this.auditor = auditor;
}
}
为了将所有这些联系在一起,我们使用 java 配置来声明 AuditorAware bean 并激活审计:
@Configuration
@EnableCouchbaseAuditing //this activates auditing
public class AuditConfiguration extends AbstractCouchbaseConfiguration {
//... a few abstract methods omitted here
// this creates the auditor aware bean that will feed the annotations
@Bean
public NaiveAuditorAware testAuditorAware() {
return new NaiveAuditorAware();
}