Продължаване на случаен UUID, служещ като ID на обект в JPA обект?

Харесва ми да използвам клас BaseDomain за всички мои JPA обекти на домейн. В базовия клас имам идентификатор на обект, съхранен като низ, генериран от UUID.random(). Идентификаторът на обекта се присвоява при създаването на обекта. Класът на обект също има първичен ключ, присвоен от базата данни, когато се поддържа.

До този момент винаги съм поддържал ИД на обект, базиран на низ. Това добавя допълнителна колона към всяка таблица, но това не ме притеснява.

Чудех се - Има ли причина да се запази идентификаторът на обекта (генерираният UUID)? Или произволният UUID трябва да остане в пространството на Java?

Винаги базирам методите hashCode() и equals() на моя клас на домейн на UUID, а не на първичния ключ. Това е добре, защото UUID остава същият за даден обект през целия му живот, както в JVM, така и в базата данни.

Ако спра да поддържам UUID, как ще изглеждат методите hashCode() и equals()? Ще бъде ли като двустепенно сравнение, като първо се използва първичният ключ, ако не е null, след това се използва идентификаторът на обекта, ако първичният ключ е null?


java uuid jpa domain-model
person user935265    schedule 07.02.2014    source източник
comment
Защо не използвате UUID като първичен ключ?   -  person Leonard Brünings    schedule 07.02.2014

Отговори (1)


arrow_upward
1
arrow_downward

Правилното внедряване на equals и hashCode наистина е голям проблем за обектите.

Не е нужно да поддържате допълнителна стойност на бизнес ключ, ако имате „естествен“ първичен ключ, като социалноосигурителен номер за дадено лице. Може да бъде една стойност или комбинация от стойности - като комбинация от име, фамилия, рождена дата и адрес. Ако имате такъв естествен PK, моля, използвайте го. Ако не разполагате с него, използването на UUID е чудесен начин да го създадете.

Ако използвате UUID за equals и hashCode, трябва също да го запазите, така че два екземпляра на един и същи запис се считат за равни.

Вашите equals и hashCode трябва да се основават на този бизнес ключ, а не на предоставения от DB идентификатор. Ако използвате идентификатора, предоставен от DB, всички нови обекти се считат за равни. Това може да доведе до неочаквано поведение, особено при работа с колекции.

person kostja    schedule 07.02.2014
comment
Твърде късно е за отговор, но той има UUID.random() в своя Base DO. И така, как новосъздаденият обект ще бъде равен, ако UUID не се използва в equal() и hashCode() - person Kay; 20.09.2018
comment
Ако нито една комбинация от атрибути не може да се използва разумно като естествен PK, тогава няма равенство на бизнес ниво, за което да говорим. Използването на преходни (напр. autoinc) или произволни PK за идентичност на бизнес обект може да причини проблеми в бъдеще, напр. срив на DB. Неизползването на такива произволни или преходни атрибути за бизнес равенство е точно смисълът. - person kostja; 20.09.2018