Rechercher un changement de comportement dans la stratégie de cascade JPA

Cette règle marque les projets JPA qui définissent des entités JPA possédant des relations qui utilisent une stratégie de cascade PERSIST, MERGE ou ALL pour vous signaler tout changement de comportement par défaut dans l'implémentation JPA 2.0 de WebSphere Application Server version 8.5 et Liberty. Avant la version 8.5, lorsqu'une persistance en cascade était appliquée, le système vérifiait dans la base de données si l'entité existait déjà. Le nouveau comportement par défaut est de ne pas vérifier d'abord, et de lancer une exception de persistance "Entity key already exists" (la clé d'entité existe déjà) si l'entité est déjà dans la base de données. Il améliore les performances car il évite tout déplacement supplémentaire dans la base de données.

Ce changement de comportement ne devrait pas avoir d'impact sur la plupart des applications. Pour bénéficier des avantages du nouveau comportement, vous pouvez d'abord tester l'application dans l'environnement de version 8.5 avant de modifier le code ou de revenir au comportement précédent.

Si vous rencontrez des problèmes ou si vous savez que votre application s'attend à ce que l'opération de persistance recherche d'abord les nouvelles entités dans la base de données et ne traite pas la nouvelle exception de persistance, vous pouvez revenir au comportement précédent en définissant la propriété openjpa.Compatibility dans le fichier persistence.xml :

< span class="Code"> < persistence-unit name="name " transaction-type = "JTA ">
...
< span class= "indent2"> < /span> < propriétés>
<property name="openjpa.Compatibility" value="checkDatabaseForCascadePersistToDetachedEntity=true"/>
</properties>
</persistence-unit>

Vous pouvez aussi définir la propriété en tant que propriété système JVM du serveur si vous ne voulez pas changer l'application.

Une règle Java et une règle XML sont associées à ce problème d'application potentiel et le mettent en évidence. Un seul résultat est marqué par projet même si une persistance en cascade est définie à plusieurs endroits. Vous pouvez ainsi rechercher ce problème dans l'intégralité de votre application.

Evaluez notamment les appels des opérations EntityManager persist et merge afin de déterminer si ce code peut traiter correctement le changement de comportement. Une fois que vous avez évalué votre application, vous pouvez désactiver cette règle dans votre configuration d'analyse ou ignorer les résultats générés.

La règle Java marque toutes les stratégies de cascade suivantes définies dans une annotation de relation :

Par exemple, les types de cascade sont marqués dans les annotations de relation telles que @OneToOne.

@Entity
public class Foo {
private Bar bar;

@OneToOne(cascade = {CascadeType.PERSIST, CascadeType.MERGE})
public Bar getBar() {
return bar;
}
}

La règle XML marque toutes les stratégies de cascade suivantes définies pour une entité dans un fichier orm.xml :

< span class="Code"> < entity class= "com.ibm.entities.Foo" access="FIELD ">
< span class= "indent2"> < /span> < attributs>
< span class= "indent4"> < /span> < one-to-one name=" bar">
<cascade><cascade-persist/><cascade-merge/></cascade>
</one-to-one>
</attributes>
</entity>

Si l'un de ces objets est marqué, vous devez évaluer le code qui appelle merge ou persist sur une entité utilisant un style de cascade persist ou merge. Si le code de l'application s'attend à ce que la base de données procède d'abord à une vérification avant d'insérer une nouvelle entité, l'application peut subir un changement du comportement.

Si vous ajoutez la propriété openjpa.Compatibility au fichier persistence.xml, exécutez à nouveau votre analyse pour vous assurer que de nouveaux résultats n'apparaissent pas dans la règle liée Rechercher un changement de comportement dans la génération de code de métamodèle JPA concernant ListAttribute.

Pour plus d'informations,