Это правило помечает проекты JPA, в которых есть сущности JPA со взаимосвязями, использующими каскадную стратегию PERSIST, MERGE или ALL, чтобы предупредить об изменении поведения по умолчанию в реализации JPA 2.0 для WebSphere Application Server V8.5 и Liberty. До версии 8.5 при каскадном сохранении база данных проверялась на наличие уже существующей сущности. Новое поведение по умолчанию - не проверять заранее и генерировать исключительную ситуацию сохранения "Ключ объекта уже существует", если этот объект уже есть в базе данных. Преимущество данного изменения - повышение производительности за счет уменьшения количества обращений к базе данных.
Данное изменение не должно затронуть большинство приложений. Для того чтобы воспользоваться преимуществом нового поведения, можно сначала протестировать приложение в среде версии 8.5, прежде чем вносить изменения в код или возвращать прежнее поведение.
Если вы сталкиваетесь с проблемами или если вы знаете, что приложение написано в расчете на то, что операция сохранения будет сначала искать в базе данных новые объекты и не будет обрабатывать новую возможную исключительную ситуацию сохранения, можно вернуться к предыдущему поведению, задав свойство openjpa.Compatibility
в persistence.xml:
|
<persistence-unit name="name" transaction-type="JTA"> ... <properties> <property name="openjpa.Compatibility" value="checkDatabaseForCascadePersistToDetachedEntity=true"/> </properties> </persistence-unit> |
Это свойство можно задать как системное свойство JVM сервера, если нежелательно вносить изменения в приложение.
Существуют правило для Java и правило для XML, предупреждающие об этой потенциальной неполадке в приложении. Помечается только один результат на проект, даже если каскадное сохранение определено в нескольких местах. Это дает возможность проверить все приложение целиком на наличие данной неполадки.
В частности, необходимо проверить вызовы операций persist и merge
интерфейса EntityManager и убедиться, что данное изменение поведения не влияет на правильность
работы кода.
После проверки приложения можно либо выключить это правило в конфигурации анализа,
либо не обращать внимания на его результаты.
Правило для Java помечает следующие каскадные стратегии, определенные в аннотации взаимосвязи:
Например, помечаются каскадные типы в таких аннотациях взаимосвязи, как @OneToOne.
|
@Entity public class Foo { private Bar bar; @OneToOne(cascade = {CascadeType.PERSIST, CascadeType.MERGE}) public Bar getBar() { return bar; } } |
Правило для XML помечает следующие каскадные стратегии, определенные для сущности в файле orm.xml:
|
<entity class="com.ibm.entities.Foo" access="FIELD"> <attributes> <one-to-one name="bar"> <cascade><cascade-persist/><cascade-merge/></cascade> </one-to-one> </attributes> </entity> |
Если любые из этих элементов помечены; необходимо проверить код, вызывающий
методы merge и persist у сущности, использующей
каскадный стиль сохранения или слияния. Если в коде приложения ожидается,
что база данных будет выполнять проверку перед вставкой новой сущности,
то поведение приложения может измениться.
Если вы добавите свойство openjpa.Compatibility в
persistence.xml, запустите анализ еще раз, чтобы убедиться, что у вас
нет новых результатов для связанного правила
Проверка изменения поведения при генерировании кода JPA MetaModel с учетом ListAttribute.
Дополнительная информация: