Вопреки комментариям @JB Низета, я могу думать о многих причинах, по которым мы позволяем триггеру назначать идентификаторы: выполнение хранимых процедур, ручное выполнение SQL-запросов и выполнение собственных запросов в Hibernate, и это только некоторые из них.
Лично я нашел следующее решение вполне удовлетворительным. Это позволяет Hibernate найти максимальный идентификатор и увеличивать его каждый раз, когда вызывается оператор вставки. Но когда оператор попадает в базу данных, идентификатор игнорируется и переопределяется идентификатором, сгенерированным триггером, поэтому уникальность в проблеме кластера :
@Id
@GeneratedValue(generator="increment")
@GenericGenerator(name="increment", strategy = "increment")
private Long id;
Самый большой недостаток - @GenericGenerator - это аннотация Hibernate, поэтому вы теряете переносимость JPA. Программистам также не ясно, что этот идентификатор на самом деле связан с последовательностью.
Другой альтернативой является изменение триггера на последовательность приращения только тогда, когда идентификатор равен нулю. См. « Проблема спящего режима с Oracle Trigger для генерации идентификатора из последовательности ». В большинстве случаев это лучшее решение, поскольку оно четко показывает, что идентификатор связан с последовательностью. Единственное, что меня беспокоит, так это то, что он дает пользователю / спящему параметру возможность вставлять любой идентификатор без фактического запроса последовательности в первую очередь.