Hibernate объект идентичности

Question

В постоянстве Java с Hibernate Гэвин предлагает использовать бизнес-ключ для сравнения на равенство. Бизнес-ключи могут не только включать в себя сравнение нескольких полей, но и нет никакой гарантии, что семантика «идеального» бизнес-ключа не изменится в будущем. Мы живем в неидеальном мире, и требования бизнеса и законы меняются очень часто. В таком случае у нас останутся данные в базе данных, которые хранятся с семантикой нескольких бизнес-ключей. Я хочу разбить проблему на две части:

1. Когда мы строго имеем дело с постоянными или отделенными объектами.

2. Когда мы имеем дело с временными объектами.

3. Я до сих пор не вижу никаких недостатков в использовании суррогатного ключа для равенства и хэш-кода, если мы имеем дело с постоянными и отделенными объектами. Два постоянных объекта или отделенные равны, если они имеют один и тот же первичный ключ. Это неправильно предполагать?

4. Когда мы имеем дело с временными объектами, мы можем использовать семантику бизнес-ключей для сравнения объектов и иметь доступную стратегию слияния, если вы попытаетесь сохранить два временных объекта с одним и тем же бизнес-ключом, но разными значениями в атрибуте Остаток.

В приложениях с интенсивным чтением, где большинство транзакций считываются / обновляются, эта стратегия должна обеспечивать более высокую производительность.

Answer 1

Раньше я мучался с поиском идеального бизнес-ключа для каждого класса и в конечном итоге использовал UUID в ситуациях, когда просто не было ничего уникального, что никогда не могло бы измениться. Но теперь я использую суррогатный ключ базы данных и избегаю ситуаций, когда мне приходится зависеть от равенства для временных объектов. Кажется, проще, менее подвержен ошибкам и быстрее. Это может зависеть от типа приложения, но для типичных приложений CRUD объект обычно попадает в базу данных, прежде чем вам придется иметь дело с ним в коллекции.

Answer 2

Проблема с идентификацией объекта и Hibernate связана с временными объектами: когда создается первичный ключ? Если ответ при записи в БД (с использованием генерации первичного ключа, управляемого БД, например, последовательности Oracle), у вас есть потенциальная проблема.

Если первичный ключ используется в качестве основы для проверки равенства и является частью генерации хеш-кода, то вы нарушите контракт хеш-кода, поскольку объект не будет прежним до и после генерации первичного ключа.

Если вы можете, просто используйте сгенерированный первичный ключ, который вы можете установить во время создания объекта (например, UUID). Это гарантирует, что ваш хэш-код и проверка на равенство остаются согласованными.