Как стать автором
Обновить

Комментарии 5

create sequence pet_seq start 1 increment 50

Добавлю, что в случае SEQUENCE при резервировании "блоками" не гарантируется непрерывное возрастание значений ID, а в случае с кластером теряется также упорядоченность. Просто был кейс, когда программист, чтобы сэкономить на индексе, сортировал события в таблице по ID вместо CREATION_TIME. Это работало на тестовых бенчах, но в кластере такая сортировка работать перестала.

В статье описывается связка "JPA – Hibernate" без конкретики по используемысм БД.

Можете ли дать ссылку на Ваши результаты тестов времени вставки при использовании разных стратегий генерации ID, для разных баз данных, для разных режимов вставки (одиночные записи/пакетная вставка), с несколькими параллельными экземплярами клиента?

А что будет, если у нас старый драйвер?

Какие версии из используемых вами драйверов можно отнести к "старым"? Вопрос больше относится к возможности провести ревизию своих репозитариев и шаблонов микросервисов.

Есть ли тесты по скорости выполнения вставок записей при использовании генерации ID в базе данных (в том числе и принудительное переопределение ID) против использования пулов из последовательностей на стороне клиента?

Использование IDENTITY не позволяет использовать пакетную вставку данных.

Это относится только к драйверам старых версий или актуально и для драйверов с поддержкой JDBC v.3?

Стратегия SEQUENCE для генерации ID может не очень хорошо себя показывать, если несколько клиентов работают с одной и той же базой.

Поделитесь, пожалуйста, примерами как можно повторить такую ошибку.

Как JPA обрабатывает ситуацию с ошибкой дублирования первичного ключа?

Свои результаты я могу нагенерить, это не очень сложно. В тексте статьи я привел ссылку на статью - https://amrutprabhu.medium.com/spring-boot-jpa-bulk-insert-performance-by-100-times-14ec10fa682b - там уже все сделано.

>Какие версии из используемых вами драйверов можно отнести к "старым"? 

"Старые" JDBC драйверы - это те, которые не поддерживают JDBC 3. У каждого вендора свои версии, я так понимаю.

>Это относится только к драйверам старых версий или актуально и для драйверов с поддержкой JDBC v.3?

IDENTITY стратегия не позволяет использовать пакетную вставку вне зависимости от версии драйвера.

>Поделитесь, пожалуйста, примерами как можно повторить такую ошибку.
Смысл в том, что другой клиент не обязан знать, что вы для генерации ID используете последовательность. Он может создать себе новую - и это приведет к коллизиям

>Как JPA обрабатывает ситуацию с ошибкой дублирования первичного ключа?
Exception выкидывает. Ничего особенного здесь нет.

А у кого ни будь было такое, что если в Entity убрать с id аннотацию @GeneratedValue
и просто генерить id руками и вставлять.
то аннотация @ManyToMany не работает, то есть он не выдает ошибку а просто
не привязывает и не пишет в таблицу связей ничего, и приходят пустые объекты вместо связанных.

В случае если используется IDENTITY можно как то сохранить объект с заданным ID ???

Зарегистрируйтесь на Хабре, чтобы оставить комментарий