Petro123Alexey TominEntity entity = new Entity(); //entity.id == null
передали в какой-то другой сервис, тот значение сохранил.
- отсоединять объект от сессии хибера нельзя
- сессия хибера должна быть как можно короче, напр 0,01 сек.
Отсюда твой пример не верен.
- либо закрой сессию и получишь ID.
Либо отсоедини от сессии и тогда объект обезличен.

Фигню пишешь.
Ещё раз- создал объект, передал в метод, который его сохранил, и теперь это другой объект - т.к. всё проверяется по equals, который (вполне возможно) включает ID.

Petro123Передал по ссылке?
Зачем его сравнивать?

Нет, не надо ничего сравнивать. Меньше кода- меньше ошибок. Лучше вообще софт не писать- ошибок и не будет.

llemingсравнивать надо, но зачем сравнивать несохраненную сущность с другой сущностью смысла нет особого.

Код пишется по принципу "меньше знаешь- крепче спишь". Поэтому код бизнес-логики может не знать, что за объект ему передан, откуда он, сохранён ли он.

Банально- оператор редактирует некий сложный объект в памяти. До попытки сохранить ему надо сказать, можно ли его будет сохранить. Для этого надо лезть в БД (иногда код реально такой, что крыша едет- бизнес, блин, требования). Но редактируемый объект надо исключить из выборки. Если есть ID- всё просто. Если нет- уже надо на null проверку лишнюю ставить- а это лишние проблемы.

llemingВсе сущности меняют ID внезапно(метод setID ведь есть) если только ID вы не генерируете на уровне app и не передаете в конструктор.

Я за суррогатный ключ всегда и везде. Как результат- ID никогда не меняется. А присвоение ID- как уже сказал- лучше делать сразу после создания, вызвав метод (который сам бегает в последовательность БД, а в дальнейшем- ещё и кэширует значения, чтобы БД не грузить, беря оттуда по 10 штук, к примеру).

А метод setId у меня всегда проверяет, что id был null (ну или 0, если long), а если не так- RuntimeException по рукам.