Например какое-то время назад встретил баг, где за пару недель сбрасывался сиквенс типа long - то есть начинали повторятся ид, что в свое время взорвало мозг
hibernate делает всякие интересные действия в транзакционных методах. При save в транзакции он моментально вызывает next у seq и id сразу становится доступным после вызова, а по факту сущность уже позже сохраняется. Это было бы невозможно если бы он не использовал такой подход. Да и serial у постгреса это sequence с привзякой к колонке, по сути он его использует просто напрямую.
Оказалось, что хибер вместо того, чтобы на каждый чих ходить в сиквенс - кешировал его значения и оптимистично выделял будующие значения сиквенса, и делал это неправильно, что-то типа след значение = текущее значение умножить на 50
Оказалось, что хибер вместо того, чтобы на каждый чих ходить в сиквенс - кешировал его значения и оптимистично выделял будующие значения сиквенса, и делал это неправильно, что-то типа след значение = текущее значение умножить на 50
Оказалось, что хибер вместо того, чтобы на каждый чих ходить в сиквенс - кешировал его значения и оптимистично выделял будующие значения сиквенса, и делал это неправильно, что-то типа след значение = текущее значение умножить на 50
Ну я понимаю, что фича, но смысл был в том, что вот такое выделение как-то неправильно сохранялось в базе, и реально получалось что у нас long id за пару недель полностью исчерпывается
у меня просто @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id;
Это у вас просто, а хибернейту надо решить, какой DDL для этого сгенерировать 😊 Вот посмотрите, какая стратегия используется, какой DDL генерируется, если вы не сами БД создаете. А если сами - то и не надо хиберу позволять таблицы делать.