Questa regola contrassegna i progetti JPA che definiscono le entità JPA con le relazioni utilizzando una strategia a cascata di PERSIST, MERGE o ALL per informare l'utente di una modifica di comportamento predefinita nell'implementazione JPA 2.0 in WebSphere Application Server V8.5 e Liberty. Prima della Versione 8.5, quando veniva eseguito il cascading di persist, veniva effettuato un controllo del database per verificare l'esistenza dell'entità. Il nuovo comportamento predefinito è di non controllare prima, e di generare una eccezione di persistenza "Chiave entità già esistente" se l'entità è già nel database. Il vantaggio della modifica al comportamento è un miglioramento delle prestazioni evitando collegamenti supplementari al database.
La modifica al comportamento non dovrebbe interessare la maggior parte delle applicazioni. Per trarre vantaggio dal nuovo comportamento, è possibile provare l'applicazione nell'ambiente della Versione 8.5 prima di apportare modifiche al codice o ripristinare il comportamento predefinito.
Se si verificano problemi o se si sa la propria applicazione è scritta
per rilevare l'operazione di persistenza alla prima ricerca nel database
delle nuove entità e non gestisce una nuova possibile eccezione
di persistenza, è possibile ritornare al comportamento precedente impostando
la proprietà openjpa.Compatibility
in persistence.xml:
|
<persistence-unit name="name" transaction-type="JTA"> ... <properties> <property name="openjpa.Compatibility" value="checkDatabaseForCascadePersistToDetachedEntity=true"/> </properties> </persistence-unit> |
La proprietà può anche essere impostata come proprietà di sistema JVM se non si desidera modificare l'applicazione.
Sono disponibili una regola Java ed una regola XML associate a questo potenziale problema dell'applicazione per aumentare la possibilità di rilevazione. Verrà contrassegnato un risultato per progetto anche cascade persist è definita in più punti. Questo fornisce la possibilità di valutare l'intera applicazione per questo problema.
In particolare, è necessario valutare le chiamate alle operazioni EntityManager
persist e merge per determinare se tale codice gestisce
in modo appropriato la modifica al comportamento.
Una volta valutata l'applicazione, è possibile disattivare questa regola nella configurazione
dell'analisi oppure ignorare i risultati generati.
La regola Java contrassegna le seguenti strategie a cascata definite in un'annotazione della relazione:
Ad esempio, i tipi di cascata verranno contrassegnati nelle annotazioni della relazione come
@OneToOne.
| @Entity public class Foo { private Bar bar; @OneToOne(cascade = {CascadeType.PERSIST, CascadeType.MERGE}) public Bar getBar() { return bar; } } |
La regola XML contrassegna le seguenti strategie a cascata definite per un'entità in un file 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> |
Se uno di tali elementi è contrassegnato, è necessario valutare il codice che richiama
merge o persist su un'entità che utilizza uno stile a cascata
persist o merge. Se il codice dell'applicazione prevede che venga eseguito il controllo del
database prima di inserire una nuova entità, nell'applicazione potrebbe verificarsi una
modifica del comportamento.
Se si aggiunge la proprietà openjpa.Compatibility a
persistence.xml, eseguire nuovamente l'analisi per assicurarsi di
non avere nuovi risultati nella regola correlata
Ricercare una modifica di comportamento nella generazione del codice JPA MetaModel relativo a ListAttribute.
Per ulteriori informazioni,