Sprawdzenie zmiany zachowania w strategii kaskadowej JPA

Ta reguła powoduje oznaczenie projektów JPA definiujących jednostki JPA z relacjami, w których używana jest strategia kaskadowa PERSIST, MERGE lub ALL, aby zwrócić uwagę na zmianę zachowania domyślnego w implementacji JPA 2.0 na serwerach WebSphere Application Server 8.5 i Liberty. W wersji wcześniejszej niż 8.5 podczas utrwalania kaskadowego była sprawdzana baza danych w celu określenia, czy jednostka już istnieje. Nowym domyślnym zachowaniem jest niesprawdzanie w pierwszej kolejności i zgłoszenie wyjątku utrwalania „Klucz jednostki już istnieje”, jeśli obiekt znajduje się już w bazie danych. Zaletą zmiany zachowania jest zwiększenie wydajności dzięki uniknięciu dodatkowych sprawdzeń w bazie danych.

Ta zmiana zachowania nie ma wpływu na większość aplikacji. Aby skorzystać z nowego zachowania, można najpierw wypróbować aplikację w środowisku w wersji 8.5 przed wprowadzeniem zmian w kodzie lub w celu przywrócenia poprzedniego zachowania.

Jeśli wystąpią problemy lub jeśli wiadomo, że aplikacja została napisana tak, że oczekuje od operacji utrwalania uprzedniego sprawdzenia w bazie danych pod kątem nowych obiektów i nie obsłuży nowego możliwego wyjątku dotyczącego utrwalania, można przywrócić poprzednie zachowanie, ustawiając właściwość openjpa.Compatibility w pliku persistence.xml:

< span class="Code"> < persistence-unit name="name " transaction-type = "JTA ">
...
< span class= "indent2"> < /span> < właściwości>
<property name="openjpa.Compatibility" value="checkDatabaseForCascadePersistToDetachedEntity=true"/>
</properties>
</persistence-unit>

Właściwość może również zostać ustawiona jako właściwość systemowa maszyny JVM serwera, jeśli zmiana aplikacji jest niepożądana.

Istnieje reguła Java i reguła XML powiązana z tym potencjalnym problemem aplikacji, aby zwrócić uwagę użytkownikowi na tę kwestię. Dla każdego projektu zostanie oznaczony tylko jeden wynik, nawet jeśli kaskadowe utrwalanie zdefiniowano w wielu miejscach. Dzięki temu użytkownik może dokonać oceny całej aplikacji pod kątem tego problemu.

W szczególności należy dokonać oceny wywołań operacji EntityManager persist i merge w celu określenia, czy ten kod odpowiednio obsłuży zmianę zachowania. Po dokonaniu oceny aplikacji można wyłączyć tę regułę w konfiguracji analizy lub zignorować wygenerowane wyniki.

Reguła Java oznaczy flagą wszystkie spośród następujących strategii kaskadowych zdefiniowanych w adnotacji relacji:

Na przykład typy kaskadowe będą oznaczane w adnotacjach relacji, takich jak @OneToOne.

@Entity
public class Foo {
private Bar bar;

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

Reguła XML oznaczy flagą wszystkie spośród następujących strategii kaskadowych zdefiniowanych dla jednostki w pliku orm.xml:

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

Jeśli dowolny z tych elementów jest oznaczony, należy ocenić kod wywołujący operację merge lub persist dla jednostki przy użyciu stylu kaskadowego persist lub merge. Jeśli kod aplikacji oczekuje, że baza danych zostanie sprawdzona przed wstawieniem nowej jednostki, może to spowodować zmianę zachowania aplikacji.

Jeśli właściwość openjpa.Compatibility zostanie dodana do pliku persistence.xml, należy ponownie uruchomić analizę, aby upewnić się, że nie ma nowych wyników związanych z pokrewną regułą Sprawdzenie zmiany zachowania w metamodelu JPA dotyczącego generowania kodu za pomocą ListAttribute.

Dodatkowe informacje: