Каждая Hibernate сущность должна иметь идентификатор, который её однозначно идентифицирует. В мире SQL подобный идентификатор называется, с некоторыми допущениями,первичный ключ. В качестве такого идентификатора можно использовать примитивные типы и их обёртки, строки, BigDecimal/BigInteger, даты и т.д. Hibernate требует, чтобы каждый такой идентификатор был:
- уникальным (UNIQUE) — то есть однозначно идентифицировал строку в таблице.
- Имеющим значение (NOT NULL) — то есть идентификтор не может быть null, а в случае составного идентификатора ни какое из его полей не может быть null.
- Неизменным (IMMUTABLE) — значение идентификатора определяется при создании записи в базе и в последствии никогда не изменяется.
Естественный ключ или суррогатный ключ
Поле идентификатора помечается аннотацией@Id. Например, если у нас в модели данных есть сущность «Компания» (а я использую модель данных из примера JPQL, в которой эта сущность есть) у которой есть имя компании и имя это соответствует требованиям к идентификаторам, то есть имеет значение, не изменяется и уникально, то это имя можно использовать как идентификатор.
|
1
2
3
4
5
6
7
8
9
10
11
12
|
@Entity
public class Company {
@Id
@Getter
@Setter
private String name;
@Getter
@Setter
@ManyToMany(mappedBy = "workingPlaces")
private Collection<Person> workers;
}
|
Такой идентификатор называется естественным. Он вытекает непосредственно из модели данных приложения и, обычно, весьма хорошо в неё вписывается. Теория так же говорит нам, что для любой таблицы/сущности можно сформировать естественный ключ.
С другой стороны, естественный ключ может быть и неудобным в использовании. Пример выше не позволяет создать компанию с тем-же самым именем в будущем, когда существующая компания уже прекратит своё существование. Поэтому зачастую используются суррогатные ключи, которые не связаны явно с моделью данных приложения, а либо порождаются из неё, либо создаются каким-либо другим способом. Типичное решение — добавление к сущности дополнительного целочисленного поля.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
@Entity
public class Company extends AbstractIdentifiableObject {
@Id
@Getter
@Setter
private Long id;
@Getter
@Setter
private String name;
@Getter
@Setter
@ManyToMany(mappedBy = "workingPlaces")
private Collection<Person> workers;
}
|
Суррогатные и натуральные ключи можно использовать параллельно:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
@Entity
public class Company {
@Id
@GeneratedValue
@Getter
@Setter
private Long id;
@NaturalId
@Getter
@Setter
private String name;
@Getter
@Setter
@ManyToMany(mappedBy = "workingPlaces")
private Collection<Person> workers;
}
|
В этом случае поле id будет первичным ключом, а name — естественным ключом. С точки зрения базы это будет просто ещё один индекс, а вот Hibernate будет знать, что это тоже идентификатор и будет использовать это знание для оптимизации. Кроме того, по естественному ключу можно делать запросы:
|
1
2
3
4
|
Company c = session
.byNaturalId( Company.class )
.using( "name", "Acme Ltd." )
.load( );
|
Простые и составные идентификаторы
Все первичные ключи, которые были в примерах выше, являются простыми ключами, то есть состоящими из одного столбца. Но первичный ключ может быть и составным, то есть состоять из более чем одного столбца. Например вы можете решить идентифицировать пользователей по паспорту, то есть серии и номеру. Очевидно, что удобнее было бы хранить серию и номер в разных полях, но тогда гарантировать уникальность значений в каждом столбце не получится и на помощь приходит составной первичный ключ.
Hibernate, разумеется, составные ключи поддерживает, причём двумя разными методами, но требует при это дополнительной работы. В первую очередь необходимо определить класс ключа:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
@EqualsAndHashCode
@ToString
public class PassportKey implements Serializable {
static final long serialVersionUID = 1L;
@Getter
@Setter
private String series;
@Getter
@Setter
private String n;
}
|
К классу ключа предъявляются некоторые требования:
- Класс должен быть public
- У класса должен быть публичный конструктор по умолчанию.
- Класс должен (корректно) реализовывать собственные equals() и hashCode()
- Класс должен реализовывать Serializable
Первый метод использования составного ключа включает класс ключа целиком в класс сущности:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
@Entity
public class Passport {
@EmbeddedId
private PassportKey key;
@Getter
@Setter
private LocalDate issueDate;
@Getter
@Setter
private Period validity;
@Getter
@Setter
@OneToOne(optional = false, mappedBy = "passport")
private Person owner;
@EqualsAndHashCode
@ToString
@Embeddable
public class PassportKey implements Serializable {
static final long serialVersionUID = 1L;
@Getter
@Setter
private String series;
@Getter
@Setter
private String n;
}
}
|
@EmbeddedId указывает на поле составного первичного ключа, а @Embeddable объявляет класс составным ключом.
Второй вариант использования оставляет поля первичного ключа непосредственно в классе сущности, а класс составного ключа служит лишь для поддержки:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
@Entity
@IdClass(Passport.PassportKey.class)
public class Passport {
@Id
@Getter
@Setter
private String series;
@Id
@Getter
@Setter
private String n;
@Getter
@Setter
private LocalDate issueDate;
@Getter
@Setter
private Period validity;
@Getter
@Setter
@OneToOne(optional = false, mappedBy = "passport")
private Person owner;
@EqualsAndHashCode
@ToString
public class PassportKey implements Serializable {
static final long serialVersionUID = 1L;
@Getter
@Setter
private String series;
@Getter
@Setter
private String n;
}
}
|
Генерируемые автоматически и создаваемые вручную ключи
Значения естественных ключей создаются естественным 🙂 образом при создании экземпляра сущности. А вот суррогатные ключи надо как-то заполнять самому и брать для них откуда-то уникальные значения, что может быть непростым делом в условиях параллельной обработки запросов.
В Hibernate на этот случай предсмотрены механизмы автоматической генерации значений суррогатных ключей, которые включается аннотацией @GeneratedValue.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
@Entity
public class Company extends AbstractIdentifiableObject {
@Id
@GeneratedValue
@Getter
@Setter
private Long id;
@Getter
@Setter
private String name;
@Getter
@Setter
@ManyToMany(mappedBy = "workingPlaces")
private Collection<Person> workers;
}
|
Когда схема базы данных создаётся Hibernate по описанию сущностей, стратегия генерации значений и необходимая для этой стратегии оснастка создаются автоматически, исходя из возможностей базы данных. Если же схема данных создаётся вручную, то описание таблиц должно совпадает с выбраной стратегией (и поддерживаться базой данных).
Hibernate поддерживает три страгегии генерации значений суррогатного ключа. Первая стратегия, GenerationType.IDENTITY, работает с базами, у которых есть специальные IDENTITY поля, например с MySQL или DB2. В этом случае, для примера выше, таблицу необходимо было бы создавать как:
|
1
2
3
4
|
CREATE TABLE COMPANY (
ID BIGINT PRIMARY KEY AUTO_INCREMENT
-- Other fields
);
|
Вторая стратегия, GenerationType.SEQUENCE, использует встроенный в базы данных, такие как PostgreSQL или Oracle, механизм генерации последовательных значений (sequence). Использование этого генератора требует как создания отдельной sequence в базе данных:
|
1
2
3
4
5
6
|
CREATE TABLE COMPANY(
ID BIGINT PRIMARY KEY
-- Other fields
);
CREATE SEQUENCE HIBERNATE_SEQUENCE START WITH 1 INCREMENT BY 1 NOCACHE NOCYCLE;
|
Так и задания имени этой sequence в описании ключа:
|
1
2
3
4
5
6
|
@Id
@SequenceGenerator(name = "hibernateSeq", sequenceName = "HIBERNATE_SEQUENCE")
@GeneratedValue( strategy = GenerationType.SEQUENCE, generator = "hibernateSeq")
@Getter
@Setter
private Long id;
|
Если явно не конфигурировать генератор последовательных значений, HIbernate будет использовать общую последовательность HIBERNATE_SEQUENCE для всех сущностей.
Третья стратегия, GenerationType.TABLE, не зависит от поддержки конкретной базой данных и хранит счётчики значений в отдельной таблице. Hibernate использует таблицу из двух столбцов, для хранения имён последовательностей и текущих значений ключа для генерации:
|
1
2
3
4
|
create table hibernate_sequences(
sequence_name VARCHAR NOT NULL,
next_val INTEGER NOT NULL
)
|
|
1
2
3
4
5
|
@Id
@GeneratedValue( strategy = GenerationType.TABLE)
@Getter
@Setter
private Long id;
|
Параметры табличного генератора могут быть настроены аннотацией @TableGenerator, по умолчанию используется таблица HIBERNATE_SEQUENCES и в ней последовательность default
UUID идентификаторы
Помимо обычных типов полей, перечисленных выше, Hibernate поддерживает использование UUID в качестве идентификатора.
UUID (Universally Unique Identifier) — это стандарт идентификации, основное назначение которого, это позволить распределённым системам уникально идентифицировать информацию без центра координации. Таким образом, любой может создать UUID и использовать его для идентификации чего-либо с приемлемым уровнем уверенности, что данный идентификатор непреднамеренно никогда не будет использован для чего-то ещё. Поэтому информация, помеченная с помощью UUID, может быть помещена позже в общую базу данных, без необходимости разрешения конфликта имен.
У использования UUID есть несколько достоинств, по сравнению с обычными автогенерируемыми целочисленными ключами:
- Обеспечивает уникальность идентификаторов не только в пределах одной таблицы, что для некоторых решений может быть важно
- Позволяет генерировать идентификатор записи на клиенте, до сохранения ее в базу
- Делает практически невозможным подбор ключа в случаях, когда запись можно получить, передав ее идентификатор в какой-нибудь публичный API
- Позволяет создавать записи в нескольких репликах базы данных и объединять их в последствии
- Типо-независим
За всё хорошее, с другой стороны, надо платить. В случае UUID ключей платить приходится производительностью:
- Генерация UUID обычно заметно медленнее, чем генерация целочисленного значения
- Выборка из таблиц, связанных друг с другом по UUID, зачастую производится медленнее.
Кроме того, UUID выглядит не очень человекочитаемым, например 452079be-cb27-4ceb-b29f-991e0c31b9e0.
Использование UUID достаточно просто:
|
1
2
3
4
5
|
@Id
@GeneratedValue
@Getter
@Setter
private UUID id;
|
Hibernate сам переключится на UUID генератор с настройками по умолчанию и будет его использовать. При необходимости можно задать и ручную конфигурацию генератора:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
@Id
@GeneratedValue(generator = "uuid")
@GenericGenerator(
name = "uuid",
strategy = "org.hibernate.id.UUIDGenerator",
parameters = {
@Parameter(
name = "uuid_gen_strategy_class",
value = "org.hibernate.id.uuid.CustomVersionOneStrategy"
)
}
)
@Getter
@Setter
private UUID id;
|
Собственный генератор
Наконец, для тех кому не хватает стандартных генераторов, в Hibernate предусмотрен механизм создания собственных генераторов. Для примера я сделаю целочисленный генератор, который создаёт случайное значение:
|
1
2
3
4
5
6
7
8
9
10
11
12
|
/**
* Generates random INT ids.
*/
public class RandomIdGenerator implements IdentifierGenerator {
private Random r = new Random();
@Override
public Serializable generate(SharedSessionContractImplementor s, Object o)
throws HibernateException {
return r.nextInt();
}
}
|
Для создания нового генератора необходимо реализовать интерфейс IdentifierGenerator и его метод generate(), который должен вернуть нагенерированное. При необходимости можно использовать текущую сессию и объект, для которого генерируется значение.
Использовать собственный генератор можно с помощью аннотации @GenericGenerator
|
1
2
3
4
5
6
|
@Id
@GenericGenerator(name = "randomGen", strategy = "ru.easyjava.data.hibernate.RandomIdGenerator")
@GeneratedValue(generator = "randomGen")
@Getter
@Setter
private Long id;
|