Использую Hibernate + Annotations. Запутался с cascadeType.

Есть к примеру связь Many-to-One




Правильно ли я указал cascadeType? Я что-то не совсем догнал, что каждый из них значит. Будет ли при удалении юзера удаляться все его ордеры? Если не сложно, может кто в двух словах объяснит, что значит каждый cascade type?

И еще один вопрос.
Имеется класс Message, в нем есть два поля типа User - fromUser и toUser


У класса User есть коллекция мессджей, которые должны делиться на входящие и исходящие.


Как правильно указать mappedBy? На что замапить? Сейчас я просто через запятую написал fromUser, toUser, но уверен, что это не сработает. Да, и как тут с cascadeType? При удалении пользователя будут удаляться все его сообщения или нет?

Про mappedBy точно могу сказть, что надо тебе две коллекции: входящие и исходящие.



Вот это не понятно: а как ты разюираешь от "кого" и "кому", если  у тебя всего лишь один форинг кей - userId

Вот о cascadeType и я бы послушал, так как у меня тоже такие траблы есть. Мое предыдущее сообщение.
Ну если в общих чертах как я понял. То какскад нужен, если у тебя большая вложенность сущностей. Для твоего примера будет где-то так:
У юзера есть мессажды, у месаждей есть файлы. И вот ты добавил несколько файлов к мессажду, а несколько удалил. А merge вызвал на юзере. Вот ты и увидешь несколько селектов, несколько инсертов, а по остальным делиты. Про DELETE FROM, конечно молчу, так получил с этим проблемы...

Да что-то и мне пока не совсем понятно :( А одной коллекцией никак не обойтись? Разбирать буду просто. Все сообщения, в которых юзер получатель - входящие, отправитель - отправленные.





Почти ничего не понял 

Сделал две коллекции.

User.java



Message.java


Хтбернейт ругается 


Если сделать, как предлагается, т.е.


То все заводится, но смущают меня эти значения insertable = false, updatable = false Это типа значит, что значение этому полю мне не присвоить и не обновить?

я же тебе говорил, что логика не верна: как ты понимаешь от "кого" "кому", если у тебя только один форинг кей на юзера? Нужно два.

Поясни логику этих вот мессаджей. 
Как я понял, кто-то отправляет кому-то мессадж. Знач мессадж должен знать об этом. А у тебя всего один userId

Кто-то отправляет кому-то мессадж, типа как ты в личку пишешь мне, а я тебе  Есть отправитель и получатель.
Я что-то сам запутался с форинг ключами. В таблице messages два форинг ключа, только ссылаются они на один и тот же первичный ключ таблицы users. Как правильно сделать?

все правильно. Ничего смертельного, что у тебя два форинг кея ссылаются на один.
У меня есть такое в пиложении:
Банк имеет форинг кей сам на себя, так как банк может филиалом и, естественно, у него есть главным банк
Есть документ заведенный в определенном банке(а может и филиале), а также в этом документе есть форинг кей на главный банк. т.е. где-то так


и все отлично работает

Вот что сгенерила моя тулза, где я БД рисовал

Что не так?

Правильно тулза сделала. 
у тебя мепинг неверный:


обратить внимание на userId в тексте!

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

Может и я что-то не понимаю. Но как мне кажеться:
1. Ты пишешь, что у тебя есть в таблице messages две колонки: toUserId, fromUserId
2. Ты меппишь сущность Message на эту таблицу. Но при этом не меппишь эти колонки.
3. Ты все указал правильно в @ManyToOne, но только у каждого User  в аннотации @JoinColumn должен быть указан не примари кей юзера, а его соответствующий форин кей из таблицы messages

MisterCleric,     Спасибо! Вреде бы все завелось!
 Я почему-то думал, что надо указывать имя праймари кей, а не форинг кей.

Едем дальше. Опять непонятки у меня с каскадностью.
Есть юнит тест.


Вот что выводит консоль


Как видно из лога, хибернейт удаляет application

Однако, если после удаления, мы у категории проитерируем коллекцию приложений, то мы все равно увидим размер коллеции 3, хотя должно быть 2

Вот маппинг у классов

Category.java


Application.java

Если удалять не так

А вот так
Тогда все нормально. Ерунда какая-то получается. Т.е. если мы у родительской коллекции удаляем елемент, то он удаляется, а если удаляем сам отдельно элемент, то он остается. Странно.

Привет еще раз.
Тут ситуация в том, что в Persistence есть такое понятие как managed & detached. Т.е. сущности, которые поцулены из базы и находятся сейчас в памяти - PersistenceContext (еще его называют кешем первого уровня). detached - те сущности, которые созданы в этом PersistenceContext, но еще не лежат в базе(а может и лежат, но PersistenceContext еще об этом не знает).
Так вот. согласно твоему примеру. У тебя не то что, может а как раз так и есть, что сущность Category заменеджена и имеет у себя внутри коллекцию applications один из элементов которой как раз и есть тот объект, который ты хочешь грохнуть.
Ты ему говоришь куском кода:


удали-ка такой-то объект из базы и PersistenceContext. Он так и сделает, но ссылка на него в коллекции-то останется... Ты же тут не сказал что ее надо убрать и из коллекции. А вот второй кусок:

Работает правильно, так как эта коллекция есть запроксированная PesistanceSet, т.е. все изменения в этой коллекции будут отделегированы PersistenceContext для выполнения соответствующих изменений: CRUD-операций.

Делаем выводы: первый кусок тоже отработает. Но надо или в отдельной транзакции его удалять, а уже потом заправшивать в другой транзакции родительскую сущность. Или надо руками из коллекции удалить, а потом вызвать удаление из базы.
вроде так...