Czy macie jakiegoś linka do dobrze opisanego JPA? Dokumentacja z strony Oracle (http://docs.oracle.com/javaee/5/tutorial/doc/bnbpy.html) wydaje mi się strasznie okrojona i lakoniczna.
Czy nowy, tworzony obiekt encji JPA może zostać przypisany do konkretnego, istniejącego już wcześniej rekordu danej tabeli w procesie "persist()" i po tym persistowaniu reprezentować go ?
Do JPA polecam: Apress Pro JPA 2 Mastering the Java Persistence API 2009
Odnosnie pytania nr2 to odpowiedz brzmi nie. Do takich celow sluzy merge() ale to nie zadziala dla nowych obiektow encji.
Dzięki, i jeszcze w takim razie :
I jeszcze jedno pytanko. Dorwałem dokumentacje JPA 2.0 ze strony Sun'a. Traktują temat miejscami szeroko a jak słyszałem w JEE czestoo jest dużo niepotrzebnych (nieużywanych) elementów. Dla Entity Magera i Persistence Context dokonują kilku wyróżnień (podziałów):
1.najpierw:
Application-Managed Entity Managers
Container-Managed Entity Managers
2.potem podział ze względu na transakcję:
JTA Entity Manager i Resource-Local Entity Manager
Czy z tego wszystkiego się realne korzysta? czy może jest jeden główny schemat implementacji EntityMagera w komponencie a reszta to duperele?
Generalnie w większych aplikacjach to jakoś zawsze tak wychodzi, że ze wszystkiego korzystasz. Dużo zależy oczywiście od konkretnego przypadku, bo niektóre aplikacje same zarządzają swoimi EM inne przerzucają to na kontener. Czasami potrzebujesz lokalnego zarządzania transakcjami czasami wystarczy automat. Co zaś tyczy się 3 punktu to > http://stackoverflow.com/questions/2547817/what-is-the-difference-between-transaction-scoped-persistence-context-and-extend
Tak, czytałem dla extended o tym że tylko dla stateful EJB i że jest Context dziedziczony do zależnych stateful beanów. Z kolei dla transacion-scoped Context istnieje tylko w ramach jednej transakcji czyli dla CMT beana transakcja to może obejmować jedną metodę tego beana (dla TransactionAttribute.Required gdy nie ma zewnętrznej transakcji). Z tego wynika że po każdym wywołaniu metody beana powstały Persisstence Context jest niszczony. Czy tak (bo trochę dziwne podejście : ))?
No i jeszcze ten podział extended i transaction-scoped jest dokonywany w ramach JTA Entity Manager. No ale JTA to też (a może głownie) transakcje z udziałem UserTransaction a wszystkie przykłady dla extended i transaction-scoped w dokumentacji przedstawili dla beanów CMT czyli bez użycia UserTransaction. Czy w takim razie te tryby extended i transaction-scoped (czyli cały zakres dla JTA Entity Manager) mogą być użyte w BMT beanie z użyciem UserTransaction? W ogóle o tym nie wspominają.
Pierce111 napisał(a)
Dzięki, i jeszcze w takim razie :
- Czyli za pomocą obiektów encji można co najwyżej dodawać nowe rekordy do bazy i ewentualnie je potem zmieniać (przez obiekty encji w trybie managed ) ale nie można się odnieść do rekordów już istniejących w bazie (powstałych poza JPA)?
- Metoda "find(params)" wywołana na EntityManger'ze może zwrócić tylko obiekty encji stworzone przez programistę w toku programu a nie zwróci obiektów encji z rekordów bazy których programista sam nie stworzył (właśnie przez encje) ?
- Jak dobrać się do "starych" rekordów bazy (niedodanych przez obiekty encji) w JPA? Czy można to zrobić przez Query czyli zapytani stworzone na EntityManager'ze (metoda CreateQuery) będące zapytaniem typu Select a potem pobrać z tego Query wynik np w formie encji JPA? W API Query jest metoda "getReasultList()" zwracająca listę wyników zapytania - może przez nią można dobrać sie do "starych" rekordów?
Metody find/createQuery służą do pobierania danych z bazy.
Nie ma znaczenia, czy dane te znalazły się tam, bo je wrzuciła aplikacja, czy też dlatego, że ktoś wykonał ręcznie insert.
Pierce111 napisał(a)
Tak, czytałem dla extended o tym że tylko dla stateful EJB i że jest Context dziedziczony do zależnych stateful beanów. Z kolei dla transacion-scoped Context istnieje tylko w ramach jednej transakcji czyli dla CMT beana transakcja to może obejmować jedną metodę tego beana (dla TransactionAttribute.Required gdy nie ma zewnętrznej transakcji). Z tego wynika że po każdym wywołaniu metody beana powstały Persisstence Context jest niszczony. Czy tak (bo trochę dziwne podejście : ))?
No i jeszcze ten podział extended i transaction-scoped jest dokonywany w ramach JTA Entity Manager. No ale JTA to też (a może głownie) transakcje z udziałem UserTransaction a wszystkie przykłady dla extended i transaction-scoped w dokumentacji przedstawili dla beanów CMT czyli bez użycia UserTransaction. Czy w takim razie te tryby extended i transaction-scoped (czyli cały zakres dla JTA Entity Manager) mogą być użyte w BMT beanie z użyciem UserTransaction? W ogóle o tym nie wspominają.
Moim zdaniem najbardziej praktycznym połączeniem jest CMT+kontekst transaction-scoped+JTA.
Jeżeli dobrze się nauczyć tego połączenia, to będziesz mógł obsłużyć 90%-100% przypadków.
Dopiero, gdy poznasz JPA lepiej proponuję naukę innych połączeń.
(jeżeli będziesz się bawić np. Jboss seam, to musisz też poznać kontekst typu extended)
Wielkie dzięki za podpowiedź.
Mam jeszcze jeden mały dylemat. Jak wstrzykiwany (np. do EJB) EntityManager rozpoznaje do jakiej bazy danych ma się odnieść?
Mam na serwerze (JBoss6) dodane trzy źródła bazy danych (local XA, dwie są MYSQL). Jak bawiłem się wcześniej na zdalnym działaniu na tych bazach (przez klienta aplikacyjnego) to z InitialContext pobierałem sobie dana bazę jako DataSource przez JNDI no a nazwa JNDI miało przyporządkowaną konkretną bazę. Tutaj dla EntityManagera nie widzę żadnego mechanizmu określenia mu na której bazie chcę działać i który Context jest mi potrzebny.
persistance.xml?
No tak, faktycznie, plik persistence.xml w projekcie (Entity) JPA pozwoli mi związać dane JPA z daną bazą. Ale co jeżeli, wewnątrz EJB chcę wykonać zapytani Query do bazy lub wyszukiwanie przez "find()" na wstrzykniętym Entity Manager'ze. Nie tworzę żadnego obiektu JPA więc skąd EntityManager będzie wiedział o którą bazę chodzi?