Проверка поведения каскадной стратегии JPA

Это правило помечает проекты JPA, в которых есть сущности JPA со взаимосвязями, использующими каскадную стратегию PERSIST, MERGE или ALL, чтобы предупредить об изменении поведения по умолчанию в реализации JPA 2.0 для WebSphere Application Server V8.5 и Liberty. До версии 8.5 при каскадном сохранении база данных проверялась на наличие уже существующей сущности. Новое поведение по умолчанию - не проверять заранее и генерировать исключительную ситуацию сохранения "Ключ объекта уже существует", если этот объект уже есть в базе данных. Преимущество данного изменения - повышение производительности за счет уменьшения количества обращений к базе данных.

Данное изменение не должно затронуть большинство приложений. Для того чтобы воспользоваться преимуществом нового поведения, можно сначала протестировать приложение в среде версии 8.5, прежде чем вносить изменения в код или возвращать прежнее поведение.

В случае неполадок и когда известно, что логика приложения предполагает предварительный поиск новых сущностей в базе данных операцией сохранения и новая исключительная ситуация не обрабатывается, можно вернуть прежнее поведение с помощью свойства openjpa.Compatibility в файле persistence.xml:

< span class="Code"> < persistence-unit name="name " transaction-type = "JTA ">
...
< span class= "indent2"> < /span> < 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:

< span class="Code"> < entity class= "com.ibm.entities.Foo" access="FIEL">
< span class= "indent2"> < /span> < атрибуты>
< span class= "indent4"> < /span> < 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.

Дополнительная информация: