Zasady zapisu zmian do bazy danych w JPA

Z każdym dniem na grupie pl.comp.lang.java pojawiają się coraz ciekawsze pytania i problemy związane z Java Persistence API (JPA) oraz Enterprise JavaBeans 3.0 (EJB3). Tym razem Marx zadał pytanie o zasady rządzące zapisem zmian encji do bazy danych w JPA - EJB3 - select robi update. W ten sposób sprowokował mnie do napisania kolejnego artykułu z serii przedstawiającej tajniki specyfikacji JPA - Zasady zapisu zmian do bazy danych w JPA.

Podobnie jak w poprzednich artykułach dotyczących JPA - Dynamiczny dostęp do wielu baz danych w JPA oraz Testowanie złączeń FETCH JOIN w JPA artykuł rozpoczyna się od przedstawienia teorii JPA, którą następnie zademonstrowałem w działaniu za pomocą aplikacji demonstracyjnej. Skorzystałem z konfiguracji projektu nadzorowanego przez Apache Maven 2, aby możliwe było uruchomienie go z 3-ma głównymi dostawcami JPA - Apache OpenJPA, Hibernate EntityManager oraz TopLink Essentials.

Drobnym acz ciekawym elementem konfiguracji Maven2 na potrzeby naszego projektu jest zależność javax.persistence.persistence-api, która występuje w wersji 1.0 w repozytorium Maven 2 oraz w wersji 1.0.2 w repozytorium Maven 1 na java.net. Biorąc pod uwagę, kto nadzoruje wersjami w repozytorium java.net (Sun) wydaje się być stosowne stosowanie bibliotek Korporacyjnej Javy właśnie z tego repozytorium. I tak też czynię w artykule.

Nauka Java Persistence z Apache Maven 2 i dostawcami JPA: OpenJPA, Hibernate i TopLink

Nic nie zastąpi nauki poprzez praktykę. Nie wszyscy mają czas, aby wszystko praktycznie sprawdzić, więc część rzeczy uczymy się wierząc słowu pisanemu. W przypadku mojej lektury specyfikacji Java Persistence API (JPA) było inaczej - zdecydowałem się na zestawienie środowiska, które zautomatyzowałoby mi wykonywanie testów jednostkowych pisanych z TestNG i jednocześnie uatrakcyjniałyby poznawanie JPA.

Najpierw powstał artykuł Java Persistence API z OpenJPA i Derby oraz TestNG z Eclipse IDE w tle, po którym dzisiejszego wieczoru napisałem kolejny będący kontynuacją wspominanego - Nauka Java Persistence z Apache Maven 2 i dostawcami JPA: OpenJPA, Hibernate i TopLink. W ten sposób nie tylko, że mogę uruchamiać proste programy (testy) bez konieczności każdorazowego zestawiania środowiska, ale również wykonywać je z wybranym dostawcą JPA - Apache OpenJPA, Hibernate oraz TopLink Essentials. A wszystko zaczęło się tak niewinnie...

Podczas lektury specyfikacji JPA rozdział 4.6 Wyrażenia warunkowe, natrafiłem na pewne zapisy, których nie mogłem zrozumieć, a może po prostu chciałem zaprezentować je w postaci kawałka kodu? Nieważne! Jak to bywało do tej pory, tak i zrobiłem i tym razem - napisałem test. Wykonałem go i ku mojemu zdziwieniu zakończył się on błędnie (tak, teraz pamiętam, to była chęć zaprezentowania tematu, a nie jego niezrozumienie ;-)). Do tej pory wszystkie testy wykonywałem z Apache OpenJPA i widząc efekt testu zacząłem podejrzewać błąd w implementacji. Postanowiłem to zweryfikować. Tylko jak?! Nie pozostało nic innego jak skorzystać z profili w Apache Maven 2 i zdefiniować trzy profile, odpowiadające poszczególnym dostawcom JPA. Po całodniowej walce w końcu się udało zestawić środowisko i dodatkowo je opisać. Okazało się również, że to, co mnie zaskoczyło, może być faktycznie błędem w OpenJPA, ponieważ uruchomienie dokładnie tego samego testu z Hibernate i TopLink kończy się pomyślnie (!) Wysłałem zapytanie na listę dyskusyjną OpenJPA-dev i oczekuję cierpliwie na odpowiedź.

Możliwość uruchamiania testów z wieloma dostawcami uzmysłowiła mi również braki w poszczególnych implementacjach specyfikacji JPA. Weźmy najpierw pod lupę Apache OpenJPA 0.9.7-SNAPSHOT. Do tej pory nie zauważyłem potencjalnie błędnego zachowania OpenJPA, aż do dnia dzisiejszego. Ważny jest jednak do zanotowania fakt, że jest to pierwsza wpadka OpenJPA. Z Hibernate EntityManager 3.3.0.GA jest znacznie, znacznie gorzej. Ot, weźmy jako przykład wsparcie dla adnotacji @NamedNativeQuery. Próba uruchomienia encji ze zdefiniowanym natywnym zapytaniem kończy się następującym błędem:

 javax.persistence.PersistenceException: org.hibernate.cfg.NotYetImplementedException: Pure native scalar queries are not yet supported
         at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:258)
         at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:120)
         at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
         at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60)
         at pl.jaceklaskowski.jpa.chapter4_6.ConditionalExpressionsTest.setUp(ConditionalExpressionsTest.java:38)

Albo jeszcze inny błąd, a właściwie niezgodność ze specyfikacją JPA, na którą natrafiłem wykonując testy, które do tej pory pomyślnie wykonywałem z OpenJPA - numerowanie parametrów pozycyjnych. Wykonanie poniższego zapytania

  SELECT DISTINCT o FROM Osoba o, IN(o.projekty) p WHERE p.rodzajProjektu = ?0

zgodnie ze specyfikacją - strona 90, gdzie napisano Input parameters are numbered starting from 1, powinno zakończyć się wyjątkiem (np. InvalidArgumentException) podczas, gdy jest akceptowane przez Hibernate. Dodatkowo, biorąc pod uwagę brak najnowszych wersji Hibernate w repozytoriach Maven 2, nie widzę powodów dla jego stosowania.

W przypadku TopLink Essentials 2.0 BUILD 40 sprawa jest najmniej kłopotliwa. Wszystko działa zgodnie z opisem w specyfikacji, co sugeruje, że chyba powinienem podmienić domyślny profil na toplink (patrz dzisiejszy artykuł).

Miłej lektury i poznawania JPA!

Przepis na środowisko do praktycznego poznawania JPA

Właśnie ukończyłem pisanie kolejnego artykułu, który jest opisem moich doświadczeń z integracji różnych projektów w celu zestawienia środowiska dla urozmaicenia lektury specyfikacji JPA. Z jego pomocą zamierzam jednocześnie czytać i programować, tj. tworzyć własne komponenty encyjne oraz wykonywać testy jednostkowe z nimi w roli głównej.

Nie tak dawno pisałem (a może jedynie myślałem o tym) o popróbowaniu się z TestNG. Było to w momencie, kiedy powracałem do lektury specyfikacji Java Persistence API (JPA), więc pomyślałem o połączeniu przyjemnego z pożytecznym, czyli o możliwości jednoczesnego testowania tego, co czytałem. Można było również inaczej postawić problem - najpierw próbować się z JPA, a później szukać wyjaśnień jej działania wertując kartki specyfikacji. Tak, czy owak nie chciałem jedynie relacjonować specyfikacji JPA, ale również prezentować możliwe zastosowania. Sprowokowało mnie to do zestawienia środowiska, w którym będę tworzył moje komponenty encyjne i aplikacje korzystające z nich oraz posiadał mechanizm wykonywania testów. Skoro dotykałem JPA to konieczna była baza danych - padło na Apache Derby. Do tego dorzuciłem Apache Maven 2 jako narzędzie spinające całość (i dostarczające wielu niewykorzystanych acz wielce produktywnych funkcjonalności), z Eclipse IDE w tle, co ostatecznie przemieniło się w bardzo produktywne środowisko do poznawania JPA w niezwykle praktyczny sposób - tworząc testy jednostkowe w trakcie lektury specyfikacji.

Początkowo miała to być jedynie relacja z moich doświadczeń, ale nie długo trwało zanim zorientowałem się, że wielkość materiału przekracza ramy relacji i wymaga stworzenia artykułu, co uczyniłem.

Jest to środowisko, które uatrakcyjni moją lekturę specyfikacji. Robi się w końcu coraz trudniej i możliwość zobaczenia tego, co się czyta wierzę, że jest ciekawym pomysłem na niwelowanie potencjalnych wybojów. Konfiguracja środowiska z wykorzystaniem JPA z Apache OpenJPA i Apache Derby oraz Apache Maven 2 i TestNG zapewnia mi powtarzalność wykonywania testów i jest jednocześnie ciekawym urozmaiceniem pogłębiania znajomości JPA. Tak "uzbrojony" jestem gotów do podjęcia się wyzwania rozpoznawania specyfikacji Java Persistence API w praktyce!

Artykuł zatytułowany jest Java Persistence API z OpenJPA i Derby oraz TestNG z Eclipse IDE w tle.

Apache OpenJPA jako dostawca JPA w samodzielnej aplikacji

Rozochocony pozytywnymi doświadczeniami pracy z JPA (w wydaniu Oracle TopLink) postanowiłem sprawić możliwości Apache OpenJPA. Obiecywałem sobie, że najpierw zajmę się Hibernate JPA (aka Hibernate EntityManager), jednakże z przyczyn ode mnie niezależnych musiałem przestawić się na OpenJPA. W zasadzie i tak planowałem ten krok, więc jedyna różnica to odwrócenie pozycji na mojej liście TODO. Udało się z OpenJPA i sądzę, że nie będzie trudno uruchomić Hibernate JPA. No cóż, zwolennicy Hibernate będą musieli zaczekać.

Doświadczenia z Apache OpenJPA spisałem w kolejnym artykule - OpenJPA jako dostawca JPA w samodzielnej aplikacji - na moim Wiki. Zapraszam do lektury i nadsyłania swoich propozycji kolejnych tematów, jeśli wałkowanie Java Persistence API zaczyna nurzyć ;-)

Miłej zabawy z JPA w wydaniu OpenJPA!