Странное поведение "один ко многим" с Spring Data JDBC

(Linked)HashSet может (в качестве побочного эффекта) сохранить один и тот же экземпляр дважды, если этот экземпляр тем временем был изменен (цитата из _2 _):

Примечание. Следует проявлять большую осторожность, если изменяемые объекты используются в качестве элементов набора. Поведение набора не указывается, если значение объекта изменяется таким образом, который влияет на equals сравнения, в то время как объект является элементом набора.

Итак, вот что, вероятно, произойдет:

1. Вы создаете новый экземпляр Address, но его идентификатор не установлен (id=null).
2. Вы добавляете его к Set, и его хэш-код вычисляется как некоторое значение A.
3. Вы вызываете PersonsRepository.save, который, скорее всего, сохраняет Address и устанавливает для него ненулевой идентификатор.
4. PersonsRepository.save, вероятно, также вызывает HashSet.add, чтобы убедиться, что адрес находится в наборе. Но поскольку идентификатор изменился, хэш-код теперь вычисляется как некоторое значение B.
5. Хэш-коды A и B сопоставляются с разными сегментами в HashSet, поэтому метод Address.equals даже не вызывается во время HashSet.add. В результате вы получите один и тот же экземпляр в двух разных сегментах.

Наконец, я думаю, что ваши сущности должны иметь _18 _ / _ 19_ семантику, основанную только на идентификаторе. Чтобы добиться этого с помощью Lombok, вы должны использовать @EqualsAndHashCode следующим образом:

@Data
@EqualsAndHashCode(of = "id")
public class Person {
    @Id
    private Long id;
    ...
}

@Data
@EqualsAndHashCode(of = "id")
public class Address {
    @Id
    private Long id;
    ...
}

Тем не менее, это не решит вашу проблему, потому что изменяется идентификатор, поэтому хэш-коды по-прежнему будут отличаться.

Один из способов справиться с этим - сохранить Address перед добавлением его в Set.

Объяснение Томаша Линковски в значительной степени верное. Но я бы поспорил за другое решение проблемы.

Внутри происходит следующее: сущность Person сохраняется. Это может создать или не создать новый Person экземпляр, если Person является неизменным.

Затем Address сохраняется и, таким образом, получает новый id, который изменяет его хэш-код. Затем Address добавляется к Person, так как это снова может быть новый экземпляр Address.

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

Что вам нужно сделать, чтобы это исправить:

Определите equals и hashCode, чтобы оба были стабильными при сохранении экземпляра

т.е. хэш-код не должен изменяться при сохранении экземпляра или в результате чего-либо еще, сделанного в вашем приложении.

Есть несколько возможных подходов.

1. основание equals и hashCode на подмножестве полей, исключая Id. Убедитесь, что вы не редактируете эти поля после добавления Address в Set. По сути, вы должны относиться к нему как к неизменному классу, даже если это не так. С точки зрения DDD это обрабатывает объект как класс значений.
2. базируйте equals и hashCode на идентификаторе и задайте идентификатор в конструкторе. С точки зрения предметной области это рассматривает класс как надлежащую сущность, которая идентифицируется своим идентификатором.