Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Pytanko o Java Persistence API

25 views
Skip to first unread message

Soren

unread,
May 26, 2007, 3:15:35 PM5/26/07
to
Witam

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

malakai

unread,
May 26, 2007, 3:36:25 PM5/26/07
to
Providerem JPA może być na przykład hibernate, więc lista wspieranych baz
może być tylko większa.


Soren

unread,
May 26, 2007, 3:44:16 PM5/26/07
to
malakai wrote:
> 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

Brzezi

unread,
May 26, 2007, 4:27:33 PM5/26/07
to
sob, 26 maj 2007 o 21:44 GMT, Soren napisał(a):

>> 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-- ]

artur.z...@gmail.com

unread,
May 26, 2007, 4:28:23 PM5/26/07
to
On 26 Maj, 21:15, Soren <java...@tlen.pl> wrote:
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 ?
>
> Wszystko się zgadza. Natomiast jest coś takiego jak JPA QL (w Hibernate nazywa się to HQL) jest to język zbliżony do SQL-a, więc zapytania też się pisze ;-) Tyle że wynikiem takiego zapytania jest obiekt/kolekcja obiektów.

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.
> JPA jako tako nie komunikuje się z bazą. Do tej komunikacji służy mu jakiś provider JPA.

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
>
> "Silnik" Hibernate może być providerem dla JPA, więc bazy danych wspierane
przez Hibernate bedą wspierane też przez JPA. Innym znanym providerem
jest
np. TopLink.

--
Pozdrawiam,
Artur

Soren

unread,
May 27, 2007, 2:45:07 PM5/27/07
to
dzięki to bardzo pomogło pozdrawiam

0x28and0x4

unread,
May 27, 2007, 4:49:31 PM5/27/07
to
artur.z...@gmail.com napisał(a):

>"Silnik" Hibernate może być providerem dla JPA, więc bazy danych wspierane
> przez Hibernate bedą wspierane też przez JPA. Innym znanym providerem
> jest
> np. TopLink.

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

Jacek Laskowski

unread,
Jun 1, 2007, 2:24:55 PM6/1/07
to
0x28and0x4 wrote:

> 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

Artur Zabronski

unread,
Jun 1, 2007, 2:54:40 PM6/1/07
to
On Fri, 2007-06-01 at 20:24 +0200, Jacek Laskowski wrote:
> Zastanawiam się, co dostarczał Hibernate czego nie było w JPA?
>
Pewnie Criteria ;-)

--
Pozdrawiam,
Artur

0x28and0x4

unread,
Jun 1, 2007, 3:24:50 PM6/1/07
to
Cześć Jacek

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!

melon

unread,
Jun 2, 2007, 3:53:25 AM6/2/07
to
On 1 Cze, 21:24, 0x28and0x4 <0x28and...@nowhere.company> wrote:
> Cześć Jacek
>
> 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...

>
> 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

Brzezi

unread,
Jun 2, 2007, 4:40:42 AM6/2/07
to
pią, 01 cze 2007 o 20:24 GMT, Jacek Laskowski napisał(a):

> 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 ][ ]

Brzezi

unread,
Jun 2, 2007, 5:00:48 AM6/2/07
to
pią, 01 cze 2007 o 20:54 GMT, Artur Zabronski napisał(a):

>> 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 ? ]

Brzezi

unread,
Jun 2, 2007, 5:06:58 AM6/2/07
to
pią, 01 cze 2007 o 20:24 GMT, Jacek Laskowski napisał(a):

> ...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 ][ ]

Jacek Laskowski

unread,
Jun 2, 2007, 5:16:23 AM6/2/07
to
0x28and0x4 wrote:

> 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.

Jacek Laskowski

unread,
Jun 2, 2007, 5:21:43 AM6/2/07
to
melon wrote:

> 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 ;-)

Jacek Laskowski

unread,
Jun 2, 2007, 5:23:18 AM6/2/07
to

Jacek Laskowski

unread,
Jun 2, 2007, 9:16:57 AM6/2/07
to
Brzezi wrote:
> pią, 01 cze 2007 o 20:24 GMT, Jacek Laskowski napisał(a):
>
>> ...i kiedy natrafiłem na problem z Hibernate,
>
> natrafiles?
...

> Czy musiales kiedys zmieniac backend ORM?

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.

0x28and0x4

unread,
Jun 3, 2007, 12:38:13 PM6/3/07
to
Brzezi napisał(a):

> pią, 01 cze 2007 o 20:54 GMT, Artur Zabronski napisał(a):
>
>>> 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 :)

Poważanie w JPA nie ma Criteria queries? Jeśli nie ma to z mojego punktu
widzenia jest to dyskwalifikujące.


Pozdrowienia,
Adam

0x28and0x4

unread,
Jun 3, 2007, 1:05:58 PM6/3/07
to
Jacek Laskowski napisał(a):

> 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.

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

Jacek Laskowski

unread,
Jun 7, 2007, 5:26:30 PM6/7/07
to
0x28and0x4 wrote:

> 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.

Artur Zabronski

unread,
Jun 7, 2007, 6:02:03 PM6/7/07
to
On Thu, 2007-06-07 at 23:26 +0200, Jacek Laskowski wrote:
> 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.
Zerkałem już na to i z tego co pamiętam zbyt wiele ten kod ma wspólnego
z Hibernate żeby sensownie dało się to przenieść na JPA ale może ja się
nie znam ;-)

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

Brzezi

unread,
Jun 8, 2007, 2:47:24 AM6/8/07
to
pią, 08 cze 2007 o 00:02 GMT, Artur Zabronski napisał(a):

> 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 ]

Jacek Laskowski

unread,
Jun 8, 2007, 3:31:30 AM6/8/07
to
Artur Zabronski wrote:

> 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 ;-)

Brzezi

unread,
Jun 8, 2007, 4:25:51 AM6/8/07
to
pią, 08 cze 2007 o 09:31 GMT, Jacek Laskowski napisał(a):

>> 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
--

Artur Zabronski

unread,
Jun 8, 2007, 5:04:07 AM6/8/07
to
On Fri, 2007-06-08 at 08:25 +0000, Brzezi wrote:
>
> Z tego co kiedys patrzylem to Criteria generuje bezposrednio SQL, ale zeby
> bylo prosciej mozna implementujac JPACriteria generowac JPAQL :)
>
No o tym myślałem, kiedyś trzeba było mi wykorzystać Criteria przy JPA
ale proste na zasadzie >/</= z dużą ilością pól to sobie napisałem taki
prosty kod na wzór API z Hibernate. Myślę że nie było by problemu by
napisać coś równie funkcjonalnego jak w Hibernate.
> Jezeli moznabyloby skopiowac klasy z Hibernate i jedynie je poprawic to
> wydaje mi sie ze nie byloby tak duzo roboty...
>
No tutaj raczej chyba tak kolorowo nie jest z tego co patrzyłem to dużo
jest zależności z Hibernate nawet w tych klasach na samym dole.

--
Pozdrawiam,
Artur

Waldemar Kot

unread,
Jun 8, 2007, 5:20:50 AM6/8/07
to
A ja liczę na to, że funkcjonalność a'la Criteria pojawi się szybciej nie w
JPA, ale w Spring'u - bo tam byłaby szczególnie użyteczna (jako
implemementacja DAO) i - zgodnie z filozofią Spring - dostępna dla wszystkich
technologii persystencji - łącznie z czystym JDBC.
Na jakiejś prezentacji Roda Johnsona to się pojawiło, że będzie w 2.1 (ale w
obecnych milestone'ach nie widzę)...

Pozdrawiam,
Waldek Kot

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

0x28and0x4

unread,
Jun 8, 2007, 6:08:45 AM6/8/07
to
Jacek Laskowski napisał(a):

> 0x28and0x4 wrote:
>
>> 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

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

0 new messages