На первом шаге проверьте таблицу генерации ключей и SEQUENCE_NAME.
Если вы используете настройку по умолчанию, вы увидите что-то следующее: адаптируйте дальнейшие шаги для другой конфигурации.
select * from hibernate_sequences;
SEQUENCE_NAME NEXT_VAL
--------------- ----------
default nnnnn
Теперь увеличьте NEXT_VAL на требуемое количество пропущенных записей. Чтобы избежать проблемы параллельной вставки через Hibernate, я использую LOCK TABLE - все вставки из Hibernate блокируются, пока вы не завершите sh действие ниже.
lock table hibernate_sequences in exclusive mode;
select * from hibernate_sequences;
-- remember the value of NEXT_VAL nnnn
update hibernate_sequences
set NEXT_VAL = NEXT_VAL + 800
where SEQUENCE_NAME = 'default';
commit;
Теперь у вас есть 800 ID nnnn + 1 .. nnnn + 800 для пропущенных строк.
Обратите внимание, что LOCK будет работать, если вы подключитесь к ВЛАДЕЛЬЦУ таблицы hibernate_sequences. Вы можете вообще пропустить LOCK, если приложение не работает и вставка невозможна.
Используйте идентичный INSERT, как вы видите в Hibernate show_sql, и с вашими данными передайте зарезервированный идентификатор.
Пример
-- Hibernate: insert into AUTHOR (name, AUTHOR_ID) values (?, ?)
insert into AUTHOR (name, AUTHOR_ID) values ('Psik', nnnn +1);
insert into AUTHOR (name, AUTHOR_ID) values ('Tuzka', nnnn+2);
Предупреждение
Как уже упоминалось в комментарии, вы должны запланировать переключение на отображение SEQUENCE, что будет сделать добавление пропущенных строк еще проще. См. Также , почему вы никогда не должны использовать таблицу-идентификатор-генератор-генератор-jpa-and-hibernate .
Сказав это, генератор TABLE может нормально работать в некоторых случаях, например, при небольшом количестве одновременных вставок. При использовании аналогичной аргументации утверждение может быть следующим: почему вы не должны использовать jpa-and-hibernate , если производительность имеет значение.