Односторонние и двусторонние отношения в Hibernate

[1nt3g3r]

Из интересных моментов, которые я сталкивался — это работа с каскадным удалением связанных сущностей.

Например, по дефолту hibernate при удалении связанных сущностей вначалей делает update связанной сущности, присваивая внешнему ключу значение null, а лишь потом удаляет связанную сущность. Фиксится поведение указанием updatable=false в аннотации @JoinColumn.

Ещё один момент — если мы указываем каскадное удаление связанных сущностей, то мы отдаем это на откуп hibernate, в БД ограничения указываются без on delete cascade. Как результат, мы не можем удалить главную сущность, не удалив всех родителей. Не всегда это нужно, и часто удобней чтобы БД контролировала ссылочную целостностность. Лечится это поведение прописыванием явным constraints в аннотации @ForeignKey.

[usharik]

Спасибо! Это интересно. У меня есть идея второй части этого материала с описанием подобных проблем/странностей. А не попадалось ли вам объяснения, почему создается таблица связей для OneToMany? Мне нигде не попадалось объяснения почему именно такое поведение выбрано дефолтным.

[poxvuibr]

А не попадалось ли вам объяснения, почему создается таблица связей для OneToMany?

Может быть потому что для того, чтобы сделать однонаправленную связь на OneToMany придётся снять ограничение not null на внешний ключ? По крайней мере я не раз встречался с ситуациями, когда из-за этого разработчики делали связь один ко многим на дополнительной таблице

[usharik]

Попробовал `@JoinColumn(name = «user_id», nullable = false)` для односторонней связи. В результате поле user_id становится not null, но связь остается через ссылочное поле.

[steff]

У меня есть идея второй части этого материала с описанием подобных проблем/странностей

Планируете ли воплотить идею в жизнь? :)

[usharik]

Планируется. Как найду время, так сразу!

[usharik]

К ставящим минусы просьба быть помногословнее) Не думаю, что для вас такая уж большая сложность сделать несколько замечаний по тексту статьи)

[poxvuibr]

Не думаю, что для вас такая уж большая сложность сделать несколько замечаний по тексту статьи)

Вы как-то очень сильно недооцениваете, насколько сложно делать замечания по тексту статьи. Чтобы понять, насколько это сложно, представьте себе, то за каждое замечание вы платите, допустим тысячу рублей )).

К ставящим минусы просьба быть помногословнее)

Я минус не ставил, но прокомментировать могу. Начну с придирок по мелочам, и потом перейдём к чему-то более серьёзному.

1. В таблице связке User_id с большой буквы.

   
   

2. В этой же таблице сontacts_id почему то во множественном числе, хотя юзер в единственном

   
   

3. Односторонняя связь рассматривается на примере связи один ко многим. А двусторонняя почему-то на примере связи многие ко многим. Если фокус статьи на unidirectional и bidirectional, то надо подробно сравнивать связи один ко многим. У вас про двунаправленую связь один ко многим написано только в конце для галочки.

   
   

4. Не сказано, что двустороння связь нужна для того, чтобы можно было сделать один insert для добавления связанной сущности, а не insert и после update

   
   

5. Не сказано, что для хорошей реализации двусторонней связи нужно сделать метод addContact и removeContact иначе разработчики будут забывать проставлять null в поле user.

   
   

6. Из-за использования коллекций и наличия методов addContact и removeContact equals роли должен сравнивать только id, а hashCode должен возвращать 31

   
   

7. Из-за того, что ключ генерируется, equals должен возвращать false, если оба Id равны null.

   
   

8. На поле user в сущности Contact не проставлен fetch = FetchType.LAZY, а значит он будет EAGER. Так делать нельзя.

   
   

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

   
   

[usharik]

Огромное вам спасибо! Во многом ради подобных комментариев я здесь и пишу)

Насчет именований в SQL, я брал тот код, который выводит Hibernate в лог. Счел не совсем корректным его изменять.

Двустороннюю связь на примере многих ко многим я разбирал потому, что так лучше видна суть проблемы (создаются две односторонние связи) и роль атрибута mappedBy.