Chciałbym się nauczyć JPA i ogólnie idei ORM. Mam jedną wątpliwość
dlatego proszę o pomoc bo nie udało mi sie tego znaleść.
Wg tego co zdążyłem przeczytać w ORM chodzi o to zeby wszystko to co
dotychczas sie robiło z bazą: inserty updaty ogólnie komendy sql'a
zastąpić operowaniem obiektami i metodami, czyli przenieść konwersacje
z bazą na grunt OOP ?
I druga chyba najważniejsza rzecz. Tego nie mogłem sie doczytać.
Czy system ORM np JPA zamienia nasze wywołania metod na komendy sql'a ?
Z tego co dobrze rozumiem to ORM musi sie komunikować z bazą a wiec musi
być jakaś lista dostępnych baz obsługiwanych przez dane rozwiązanie ORM.
Udało mi sie znaleśc to dla hibernate'a http://www.hibernate.org/80.html
ale nie moge znaleść dla JPA. Gdzie jest lista dostępnych baz dla JPA.
Google nei pomogło PLZ
Proszę o wyjaśnienie moich błędów niejasności w rozumowaniu ORM
Z góry dziękuję i pozdrawiam
>> Providerem JPA może być na przykład hibernate, więc lista wspieranych baz
>> może być tylko większa.
> a czy JPA i Hibernate to nie dwa różne rozwiązania ORM ?
> nie rozumiem za bardzo
JPA to tylko "API", Hibernate jest tylko konkretna implementacja
Pozdrawiam
Brzezi
--
[ E-mail: brz...@enter.net.pl ][ GEEK CODE [Version: 3.12]: GCM dpu s+:- ]
[ Ekg: #3781111 ][ a--- C+++ UL++ P+ L+++ E--- W+++ N+++ ]
[ LinuxUser: #249916 ][ o-- K- w--- O-- M- V- PS PE Y PGP--- t+ ]
[ 5- X++ R* tv+ b- DI- D+ G+ e- h! r y-- ]
--
Pozdrawiam,
Artur
Dorzucę do tego, swoje 3 ełrocenty.
Na stronie http://java.sun.com/javaee/overview/faq/persistence.jsp
możemy przeczytać:
<quote>
Q: What are the advantages of the Java Persistence API?
A: The Java Persistence API draws upon the best ideas from persistence
technologies such as Hibernate, TopLink, and JDO. Customers now no
longer face the choice between incompatible non-standard persistence
models for object/relational mapping. In addition, the Java Persistence
API is usable both within Java SE environments as well as within Java
EE, allowing many more developers to take advantage of a standard
persistence API.
</quote>
I tu jest chyba - z mojego punktu widzenia - jedno z najbardziej
kontrowersyjnych stwierdzeń odnośnie JPA i Hibernate. To prawda, że
użycie w projekcie czegoś co jest standardem (tutaj: JPA) jest kuszące i
może się (na pierwszy rzut oka) wydawać bezpieczniejszym wyborem.
Niemniej ostatnio stojąc przed podobnym wyborem, gdzie miałem wybrać ORM
, który zastosuję w swoim projekcie, wybrałem jednak Hibernate. Uznałem,
że bezpieczniejszym wyborem jest właśnie Hibernate, ponieważ uznałem, że
jest on rozwiązaniem dojrzalszym, dającym większe możliwości. Co z tego,
że nie jest to tzw. standard. Nie oszukujmy się, czy ktoś z nas brał
udział w projekcie, gdzie dopiero w dalszych fazach implementacji
postanowiono zmieniać silnik ORM pomiędzy technologiami np.
Hibernate/JDO/TopLink/JPA? Zmiana silnika ORM wiąże się z głębokimi
zmianami samego kodu.
Dodatkowo w starej (bo z 2004) prezentacji:
http://www.hibernate.org/hib_docs/online/atljug04_presentation/hibernate_atljug2004.pdf
... o Hibernate można znaleźć jedno z bardziej trafnie opisujących ten
framework zdań: "Mature software driven by user requests".
Innymi słowy cykl pomiędzy datą stwierdzenia, że warto zaimplementować
jakąś nową funkcjonalność, a datą dostarczenia tego wraz z nową wersją
Hibernate jest zapewne krótszy niż będzie to miało w przypadku bardziej
sztywnych standardów takich jak JPA.
Aczkolwiek JPA może nabierać swojego znaczenia w przypadku aplikacji
J2EE/JEE, gdzie wymaganie przenośności pomiędzy serwerami aplikacyjnymi
może być kluczowe.
Reasumując:
Stojąc przed wyborem JPA czy Hibernate, bez wahania wybrałem Hibernate.
Pozdrowienia,
Adam
> Reasumując:
> Stojąc przed wyborem JPA czy Hibernate, bez wahania wybrałem Hibernate.
...i kiedy natrafiłem na problem z Hibernate, nie miałem odwrotu, gdyż
ilość kodu specyficznego dla niego była nie-do-przepisania. Oh, gdybym
korzystał z Hibernate, gdzie tylko musiałem, a w pozostałych miejscach
korzystał z rozwiązań zgodnych z JPA, to mógłbym przejść do równie
dojrzałych rozwiązań, jak TopLink czy OpenJPA.
Dobrze jest mieć wybór.
Zastanawiam się, co dostarczał Hibernate czego nie było w JPA?
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
--
Pozdrawiam,
Artur
Jacek Laskowski napisał(a):
>> Reasumując:
>> Stojąc przed wyborem JPA czy Hibernate, bez wahania wybrałem Hibernate.
>
> ....i kiedy natrafiłem na problem z Hibernate, nie miałem odwrotu, gdyż
> ilość kodu specyficznego dla niego była nie-do-przepisania. Oh, gdybym
> korzystał z Hibernate, gdzie tylko musiałem, a w pozostałych miejscach
> korzystał z rozwiązań zgodnych z JPA, to mógłbym przejść do równie
> dojrzałych rozwiązań, jak TopLink czy OpenJPA.
>
> Dobrze jest mieć wybór.
>
> Zastanawiam się, co dostarczał Hibernate czego nie było w JPA?
Moje obserwacje (i wnioski) to wynik skrzywienia zawodowego. OD jakiegoś
czasu piszę system, który osadzony jest w bazie danych (Oracle, dość
starej), której struktury już istniejących tabel nie mogę zmieniać.
Częścią tego projektu jest przepisanie sporej ilości kodu w Oracle
PL/SQL do Java+Hibernate. W owym kodzie PL/SQL jest kilka konstrukcji
stricte Oraclowych, których nie sposób znaleźć ani w JPA, ani w
Hibernate. Za to Hibernate - według mnie - lepiej obsługuje Native SQL
niż JPA.
Na temat natywnych zapytań dokumentacja OpenJPA ma półtora ekranu tekstu:
http://openjpa.apache.org/docs/latest/manual/manual.html#jpa_overview_sqlquery
Hibernate ma o tym ekranów 9:
http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#querysql
W szczególności w OpenJPA nie mogę znaleźć mechanizmu "16.1.4. Returning
multiple entities":
http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#d0e13126
Chyba nasze nieporozumienie wynika z tego, że ja przez bezpieczeństwo
rozumiem tu akurat lepsze wsparcie dla "legacy Oracle databases",
natomiast Ty łatwą możliwość podmienienia silnika JPA w projekcie, jeśli
taka konieczność nastąpi.
Aaaa... I jasne, że argumenty związane z native queries są tematami
smutnymi i obślizgłymi (w końcu to zeszłowieczna technologia), ale kiedy
trzeba pracować z właśnie takimi bazami obsługa takich baz i starego
kodu SQL lub PL/SQL staje się kluczowa.
Pozdrowienia,
Adam Woźniak
PS.
Byłem na kilku Twoich prezentacjach w MIMUW. Teraz "zarobiony jestem" i
nie mam na to czasu. Szkoda, bo spotkania są super!
Nie znam się na JPA aż tak dobrze, ale jak dla mnie to ta technologia
sprawdza się kiedy robimy wszystko od nowa i nie mamy za dużo
naleciałości właściwych dla konkretnej bazy danych itp.
Jeśli chcesz wołać nativeQueries to może lepiej użyć iBATIS'a
Melon
> Zastanawiam się, co dostarczał Hibernate czego nie było w JPA?
http://www.hibernate.org/hib_docs/annotations/reference/en/html_single/#entity-hibspec
http://www.hibernate.org/hib_docs/annotations/reference/en/html_single/#additionalmodules
http://www.hibernate.org/hib_docs/shards/reference/en/html_single/
http://www.hibernate.org/hib_docs/validator/reference/en/html_single/
http://www.hibernate.org/hib_docs/search/reference/en/html_single/
:)
Pozdrawiam
Brzezi
--
[ E-mail: brz...@enter.net.pl ][ It's bad enough that life is a rat-race, ]
[ Ekg: #3781111 ][ but why do the rats always have to win? ]
[ LinuxUser: #249916 ][ ]
>> Zastanawiam się, co dostarczał Hibernate czego nie było w JPA?
> Pewnie Criteria ;-)
O wlasnie, o tym zapomnialem napisac w moim poscie obok, a to w sumie
najwazniejsze :)
Przypadki w ktorych stosuje HQL zamiast criterii to jakies 5-10%, i glownie
ze wzgledu na czas, bo pewnie daloby sie to napisac w Criterii, ale akurat
HQL na brudno mozna to szybciej naskrobac...
Criteria pokazuje swoja potege przy np. potokowym/lancuchowym generowaniu
query, np. podczas wyszukiwania...
List browseCos(BrowseComand browse, SearchCommans search){
Criteria criteria = getCurrentSession.createCriteria(Cos.class);
addOrder(criteria, browse); // dodaje sortowanie
addPaging(criteria, browse); // ustawia stronicowanie
addSearch(criteria, search); // dodaje ograniczenia z wyszukiwarki
addRestrictions(criteria, browse); // dodaje np. ograniczenia dla
// zalogowanego usera
return criteria.list();
}
nie musisz sie przejmowac kolejnoscia dodawania oreder/where/group/limit,
tym zajmie sie criteria
Za pomoca HQL nawet nie widze mozliwosci jak to ladnie rozdzielic na takie
tworzenie zapytania w sekwencyny sposob, bo najpierw tworzysz stringa HQL,
np. z nazwanymi parametrami, a dopiero po stworzeniu Query mozesz nadawac
im wartosci..., wiec pewnie trzebabyloby kazda operacje wykonac dwa razy,
najpierw np. addSearch(String hql, browse), a potem po wykonaniu innych,
znowu addSearch(Query query, browse);
Pozdrawiam
Brzezi
--
[ E-mail: brz...@enter.net.pl ][ <cabko> jak zainstalowac linuxa, bo nie ]
[ Ekg: #3781111 ][ chce mi sie zaden program ]
[ LinuxUser: #249916 ][ instalacyjany pod windows 98 ]
[ odpalic ? ]
> ...i kiedy natrafiłem na problem z Hibernate,
natrafiles?
> nie miałem odwrotu, gdyż
> ilość kodu specyficznego dla niego była nie-do-przepisania. Oh, gdybym
> korzystał z Hibernate, gdzie tylko musiałem, a w pozostałych miejscach
> korzystał z rozwiązań zgodnych z JPA, to mógłbym przejść do równie
> dojrzałych rozwiązań, jak TopLink czy OpenJPA.
>
> Dobrze jest mieć wybór.
Czy musiales kiedys zmieniac backend ORM?
przewinelo sie przez moje palce sporo projektow, ktore to badz tworzylem od
podstaw, badz dochodzilem do nich w trakcie, wszystkie wykorzystywaly
Hibernate, nie przypominam sobie raczej zadnych problemow, przynajmniej
takich ktorych nie dalo sie rozwiazac, a juz napewno nigdy nie bylo nawet
mysli w zespole aby zmienic Hibernate na cokolwiek innego
W zadnym wypadku nie pisze ze Towje zdanie na ten temat to brednie, tylko
przedstawiam spojrzenie na problem z innej strony
Pozdrawiam
Brzezi
--
[ E-mail: brz...@enter.net.pl ][ ]
[ Ekg: #3781111 ][ Klein bottle for rent -- inquire within. ]
[ LinuxUser: #249916 ][ ]
> Na temat natywnych zapytań dokumentacja OpenJPA ma półtora ekranu tekstu:
> http://openjpa.apache.org/docs/latest/manual/manual.html#jpa_overview_sqlquery
>
>
> Hibernate ma o tym ekranów 9:
> http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#querysql
>
> W szczególności w OpenJPA nie mogę znaleźć mechanizmu "16.1.4. Returning
> multiple entities":
> http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#d0e13126
Dzięki za wskazówki. Poczytam sobie.
> Aaaa... I jasne, że argumenty związane z native queries są tematami
> smutnymi i obślizgłymi (w końcu to zeszłowieczna technologia), ale kiedy
> trzeba pracować z właśnie takimi bazami obsługa takich baz i starego
> kodu SQL lub PL/SQL staje się kluczowa.
Dobrze mieć na pokładzie pragmatyka (Ty) a nie napaleńca (Ja). Dobrze
jest w końcu skończyć projekt w planowanym terminie, nieprawdaż? ;-)
> PS.
> Byłem na kilku Twoich prezentacjach w MIMUW. Teraz "zarobiony jestem" i
> nie mam na to czasu. Szkoda, bo spotkania są super!
A ja widzę przyszłego prelegenta - Ciebie! Właśnie takie tematy są
fascynujące, bo działają jak kubeł zimnej wody na rozgrzane głowy
napaleńców. Dałoby się coś wykombinować na 19.06? ;-) 5 slajdów, dużo
opowiadania, kilka kawałków kodu, gdzie JPA sucks itp. Poklepywanie po
plecach jest fajne, ale czasami kubeł zimnej wody jest bardziej uczący.
Możemy nawet wspólnie podejść do tematu. Pisz na priv.
> Nie znam się na JPA aż tak dobrze, ale jak dla mnie to ta technologia
> sprawdza się kiedy robimy wszystko od nowa i nie mamy za dużo
> naleciałości właściwych dla konkretnej bazy danych itp.
Eee, może właśnie brak doświadczenia jest źródłem sceptycyzmu. I nie
traktuj tego osobiście - ja należę do tej samej grupy nowicjuszy, co Ty,
a że kilka razy coś tam napisałem/opowiedziałem....hm jedynie dużo szumu ;-)
Aby konkretnie poprowadzić dyskusję proponuję, abyś zaprezentował
problem i przegadamy go tutaj. Wspólnie znajdziemy odpowiedź, nawet
jeśli miałaby brzmieć JPA jest do kitu w tym zastosowaniu, ale niezwykle
pomocne w innym. Ważne, aby właściwe narzędzie użyć do tematu, dla
którego powstał. Przecież, parafrazując Piotr Kobzdę z konferencji, mamy
różne rodzaje młotków i nie wszystkie używasz do wbijania gwoździa pod
obrazek na ścianie.
> Jeśli chcesz wołać nativeQueries to może lepiej użyć iBATIS'a
Kolejna osoba o tym wspomina. Poczytałem trochę o tym na blogu Mariusza
L., ale nie czuję go jeszcze. Chyba dojrzewam do chwili, w której dotknę
go...czulej ;-)
Taaa, potrafisz urozmaicić człowiekowi weekend. Nie dziękuję! ;-)
Problem w tym, że kiedy intensywnie tworzyłem oprogramowanie, to nie
miałem wiedzy, a teraz kiedy ją mam, mówią, że jestem zbyt drogi, więc
jak na początku się nie wstrzelę/doradzę to klapa.
A czy wyobrażam sobie zmianę ORM? I tak i nie. Mam świadomość, że wielu
z nas, kiedy rozpocznie projekt z produktem X nie ma ochoty migrować do
produktu Y i nie dlatego, że jest lepszy/gorszy, ale dlatego, że się nie
chce.
Poważanie w JPA nie ma Criteria queries? Jeśli nie ma to z mojego punktu
widzenia jest to dyskwalifikujące.
Pozdrowienia,
Adam
Jacek, ja w żadnych przypadku nie mówię, że JPA jest gorsze od Hibernate
(lub na odwrót). Nie znam JPA na tyle, aby pokusić się o porównywanie do
Hibernate. Kiedyś nawet, po jednym ze spotkań na MIMUW, nawet
wspominałem Tobie mój plan przedstawienia Hibernate na jednej z sesji,
ale ... "zarobiony jestem" :( A więc, jak na razie, nie widzę możliwości
występu dla Warszawa-JUG :( Poza tym z racji, że Hibernate od tak dawna
osadzony jest na rynku, czy ktoś byłby zainteresowany taką "starą"
technologią? ;)
btw:
Alarmujące wieści napisali Brzezi i Artur Zabronski, którzy donieśli, że
w JPA nie ma Criteria queries :>
btw:
Nie wiem czemu, ale jestem gorącym kibicem projektu OpenJPA i trzymam za
niego kciuki! :)
Pozdrowienia,
Adam Woźniak
> W szczególności w OpenJPA nie mogę znaleźć mechanizmu "16.1.4. Returning
> multiple entities":
> http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#d0e13126
Mnie się w końcu udało! Opisałem to w moim Notatniku z gratulacjami za
inspiracje dla Ciebie ;-)
http://jlaskowski.blogspot.com/2007/06/java-persistence-83-adnotacje-zapyta.html
p.s. Niestety Criteria API to wciąż cudo dostępne w Hibernate a nie JPA.
Jednakże zastanawiam się, czy implementację Criteria nie możnaby
przenieść na JPA?! W końcu, gdzieś nisko musi być tworzenie zapytania i
to zapewne przy pomocy wzorca Visitor, czy podobnie.
Kod nie wygląda na jakoś strasznie obszerny i zawiły:
(artur@ubuntu)(9/pts/0)(11:58pm:06/07/07)-
(%:~/java/src/Hibernate3/code/core/src/main/java)- find . -name
'*Crit*.java' | xargs wc -l
575 ./org/hibernate/impl/CriteriaImpl.java
337 ./org/hibernate/Criteria.java
556 ./org/hibernate/loader/criteria/CriteriaQueryTranslator.java
174 ./org/hibernate/loader/criteria/CriteriaJoinWalker.java
169 ./org/hibernate/loader/criteria/CriteriaLoader.java
125 ./org/hibernate/criterion/DetachedCriteria.java
55 ./org/hibernate/criterion/CriteriaSpecification.java
44 ./org/hibernate/criterion/Criterion.java
45 ./org/hibernate/criterion/SQLCriterion.java
91 ./org/hibernate/criterion/CriteriaQuery.java
2171 total
Może są chętni żeby w wolnych chwilach napisać coś podobnego pod
JPA? ;-) Skończyło by się wiecznie wypominanie brak criteria queries w
JPA ;-)
--
Pozdrawiam,
Artur
> Kod nie wygląda na jakoś strasznie obszerny i zawiły:
> (artur@ubuntu)(9/pts/0)(11:58pm:06/07/07)-
> (%:~/java/src/Hibernate3/code/core/src/main/java)- find . -name
> '*Crit*.java' | xargs wc -l
Zle szukasz, criteria to nie tylko klasy zaczynajace sie na Crit*, zajrzyj
poprostu do pakietu org.hibernate.criterion, jest tez sporo klas
pomocniczysz...
Pozdrawiam
Brzezi
--
[ E-mail: brz...@enter.net.pl ][ A baby is God's opinion that the world ]
[ Ekg: #3781111 ][ should go on. ]
[ LinuxUser: #249916 ][ -- Carl Sandburg ]
> Może są chętni żeby w wolnych chwilach napisać coś podobnego pod
> JPA? ;-) Skończyło by się wiecznie wypominanie brak criteria queries w
> JPA ;-)
A co mi tam. Zajrzeć można, a że nic z tego nie wyjdzie (jak zwykle), to
inna bajka ;-)
>> Może są chętni żeby w wolnych chwilach napisać coś podobnego pod
>> JPA? ;-) Skończyło by się wiecznie wypominanie brak criteria queries w
>> JPA ;-)
> A co mi tam. Zajrzeć można, a że nic z tego nie wyjdzie (jak zwykle), to
> inna bajka ;-)
Z tego co kiedys patrzylem to Criteria generuje bezposrednio SQL, ale zeby
bylo prosciej mozna implementujac JPACriteria generowac JPAQL :)
Jezeli moznabyloby skopiowac klasy z Hibernate i jedynie je poprawic to
wydaje mi sie ze nie byloby tak duzo roboty...
Pozdrawiam
Brzezi
--
--
Pozdrawiam,
Artur
Pozdrawiam,
Waldek Kot
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Nie przypuszczałem, że native queries w rozwiązaniach ORM mogą być dla
kogoś tak intrygujące ;) Dziękuję za Twój wpis na Twoim blogu w tym
temacie (właśnie jestem po jego lekturze).
> p.s. Niestety Criteria API to wciąż cudo dostępne w Hibernate a nie JPA.
> Jednakże zastanawiam się, czy implementację Criteria nie możnaby
> przenieść na JPA?! [..]
Odnoszę wrażenie, że trochę Panowie mieszają tematy. W takim razie
zastanawiacie się, czy dodać Criteria API do oficjalnej specyfikacji
JPA, czy po prostu zaimplementować to w OpenJPA?
Pozdrowienia,
Adam Woźniak