В моем приложении Spring-data-jpa я использую пакетную функцию для вставки нескольких тысяч записей. Я ищу эффективный способ определения записи, которая вызывает сбой пакета по разным причинам.
У меня установлены следующие свойства
spring.jpa.properties.hibernate.jdbc.batch_size=15
spring.jpa.properties.hibernate.order_inserts=true
spring.jpa.properties.hibernate.order_updates=true
#app.writeSize is meant to collect writeSize of records before calling saveAll()
app.writeSize=100
Как я уже говорил, мой размер пакета JPA равен 15, но приложение будет ждать, пока не соберет 100 записей (writeSize), прежде чем вызывать метод saveAll () в хранилище.
Основываясь на примере, предоставленном в https://vladmihalcea.com/how-to-find-which-statement-failed-in-a-jdbc-batch-update/, Я реализовал обработку исключений, самоанализ для BatchUpdateException и getUpdateCounts (). Length, чтобы получить записи, которые были успешно обновлены перед выдачей ошибки.
Этот подход работает нормально, пока я сохраняю свой пакет JPA и writeSize одинаковыми.
Но результаты не соответствуют, если я изменяю writeSize. У меня есть теория и, возможно, правильное понимание, почему она не соответствует. Я полагаю, так как saveAll () работает над writeSize записей, но фактические пакетные вставки внутренне происходят только для 15 записей. В каждой итерации репозиторий JPA внутренне выдает INSERTS для 15 записей, пока все 100 записей не будут вставлены, и не выдаст сброс (я вызываю сброс).
Но поскольку сбой может произойти в любой из этих 15 итераций записи, результаты меняются, так как я меняю writeSize.
Так есть ли лучший способ точно идентифицировать запись, не сохраняя JPA и размер записи не равен.
Спасибо