ловушки коллекций сущностей в Hibernate

Question

ОК, это следующий вопрос к this one, так как я действительно запутался.

Предположим, у меня есть один-ко-многим или многие-ко-многим ассоциации между объектами Person и Event такой, что Person класс в Java содержит Set<Event>. (Давайте проигнорируем, содержит ли событие один Person или Set<Person>.)

Event s - это объекты, хранящиеся в базе данных, поэтому я могу изменить поля событий. Каков правильный способ обработки Event изменчивости и не получить набор Java <> проверка подлинности путается? Вы не должны переопределять hashCode() и/или equals() в этом случае? (например, идентификация = на основе идентификатора ссылки на объект)

Если я хочу, чтобы заказываемые Event s (например, по времени начала события), как мне управлять изменением полей Event? База данных прекрасно справится с этим, как только изменение будет распространено там, но на стороне Java это означает, что для изменения события в коллекции мне нужно удалить его, изменить его и повторно вставить? Или нет реального способа сохранить отсортированный порядок на Java-стороне сопоставления Hibernate? (И, следовательно, я должен относиться к нему как неупорядоченные и поэтому обрабатывать сортировку в Java, когда я хочу, чтобы получить отсортированный список Event с?)

редактировать: Тьфу, я только что нашел эти дискуссии на равных/хэш-код:

• Hibernate website
• a blog

Answer 1

это не ловушка вообще, это соблюдение семантики вы сказали, что ожидать. Реальная проблема: «Что происходит с равенством, когда меняются так называемые ключевые поля». Да, это выходит прямо из окна. Итак, да, вы можете оказаться в ситуации, когда кто-то меняет поле в вашем наборе, что делает его равным другому, на основе этих ключей. Да, ваша бизнес-логика должна справиться с этим. Когда вы обновляете объект Event, вы должны убедиться, что новые значения действительны не только для поля, но и для контекста, в который вы их вставляете. В этом случае вы не можете разрешить дублирование объекта события для дублирования существующее событие. Эта проблема еще более уродлива в SQL.