Невозможно определить, какая запись вызывает исключение оракула Spring DATA JPA

Question

У меня есть метод, который аннотирован @Transactional, и мы производим массовое обновление, используя метод save (Iterable entity) класса SimpleJPARepository из библиотеки spring-data-jpa.У меня есть сценарий, где у меня есть около 20000 записей обрабатываются этим методом.Кажется, что есть немного объектов, которые не были бы хорошо сформированы с точки зрения типов данных, как ожидает колонка оракула.Например: имя атрибута «имя объекта» имеет значение «1234» (которое не принимается Oracle-БД в качестве типа данных в БД - VARCHAR).

Поскольку эта проблема возникает в нескольких записях из 20000 записей, сохраните (Метод итерируемых сущностей) выдает исключение «java.sql.SQLSyntaxErrorException: ORA-01722: неверный номер» и не сохраняет ни одну из 20000 записей.Есть ли способ определить, какие записи вызывают это исключение, и исключить их обновление в базе данных?

Я вижу, что есть несколько вариантов, таких как проверка в классах DOMAIN (что не очень выполнимо для меня, так как у меня много классов Domain, и изменение их будет иметь большое влияние на мое приложение).Еще одна опция, которую я вижу, использует «пакетные вставки JPA с Hibernate».Опять же, даже при таком подходе пакетных вставок я не уверен, смогу ли я получить информацию о записях, которые вызывают исключение.

Любые предложения по этому вопросу будут очень полезны.

Answer 1

По-видимому, вы пытаетесь позволить базе данных проверять ваши данные.

Я вообще считаю, что это плохая идея, но она не работает с JPA.

Даже если вы заявили, что не хотите исправлять модель сломанного домена, это именно то, что вы должны сделать:

• изменить сущности так, чтобы используемые типы совпадали с используемыми в базе данных. Обратите внимание, что попытка сохранить значение "1234" или 1234 в столбце VARCHAR или VARCHAR2 не вызовет исключение ORA-01722: invalid number, поскольку ничто не пытается преобразовать что-либо в число, и даже если это произойдет, оба значения являются числом или легко разбираются в число.

• добавить проверку для обеспечения тех ограничений, которые не могут быть выражены типами (например, длина строк).

Альтернативой может быть процесс, подобный следующему:

1. Сохранять партию сущностей.

2. Если успешно завершить коммит. Готово.

3. Если это не удается, разбейте партию на более мелкие партии и повторите процедуру с 1.

Это уродливо и медленно, и может помочь найти все ограничения, которые нужно проверить, но это не хороший способ отфильтровать те записи, которые плохо воспроизводятся в вашей базе данных.