JPA, encja dziedzicząca i informacja o klasie
JK
User,
Student extends User,
Profesor extends User.
Dyskryminatory poustawiane na kolumnie userType integer
Mam zapytanie:
SELECT u.id, u.firstName, u.lastName FROM User, kt�re zwraca zwraca
�adny Object[]{int,String,String}
I teraz chcia�bym jeszcze zna� klas� ka�dego z wynik�w, ale
paradoksalnie dopisania u.class nie zwraca klasy tylko warto�� int
dyskriminatora. Czy takie powinno byďż˝ zachowanie JPA? Czy jest jakiďż˝
spos�b poza r�cznym na zresolvowanie tych int�w na Class<? extends
Profesor>?
--
JK | http://www.all-exclusive.pl/ | http://jakprzetrwac.pl
Jarek
news:hd9g5n$f5c$1...@inews.gazeta.pl...
A nie mo�esz mie� po prostu
SELECT u from User u
i zobaczy� jakiej klasy obiekt zosta� zwr�cony.
Czy masz jakie� wielkie pola, kt�rych nie chcesz �adowa�?
Pozdrawiam
Jarek
JK
>
> SELECT u from User u
>
> i zobaczy� jakiej klasy obiekt zosta� zwr�cony.
> Czy masz jakie� wielkie pola, kt�rych nie chcesz �adowa�?
Og�lnie jest tak, �e beany maj� bardzo du�o p�l, na list� jest
potrzebnych tylko kilka. Lazy loading p�l ManyToOne jest w JPA mo�liwy,
ale przynajmniej w Hibernate wyskakuj� p�niej problemy z serializacj�
(beany sďż˝ one pobierane przez klienta zdalnego klienta EJB). Pewnym
rozwi�zaniem by�yby tzw. field sety (czyli zestawy p�l do �adowania),
ale na razie taka funkcjonalno�� jest chyba tylko w OpenJPA i nie jest
elementem standardu.JPA. Zresztďż˝ patent z tablicami sprawdza siďż˝ bardzo
dobrze, w razie potrzeby wy�wietlenia czego� z innej tabeli zawsze mo�na
zrobi� �adnego JOIN'a EJB-QL. Zapytania SQL generowane w ten spos�b
wygl�daj� znacznie lepiej ni� niekt�re "potworki" (�adowanie po�owy
bazy), kt�re mog� si� tworzy� przy �adowaniu ca�ych obiekt�w.
Kolo
> > A nie możesz mieć po prostu
>
> > SELECT u from User u
>
> > Czy masz jakieś wielkie pola, których nie chcesz ładować?
>
> Ogólnie jest tak, że beany mają bardzo dużo pól, na listę jest
> potrzebnych tylko kilka. Lazy loading pól ManyToOne jest w JPA możliwy,
> ale przynajmniej w Hibernate wyskakują później problemy z serializacją
> (beany są one pobierane przez klienta zdalnego klienta EJB). Pewnym
> rozwiązaniem byłyby tzw. field sety (czyli zestawy pól do ładowania),
> ale na razie taka funkcjonalność jest chyba tylko w OpenJPA i nie jest
> elementem standardu.JPA. Zresztą patent z tablicami sprawdza się bardzo
> dobrze, w razie potrzeby wyświetlenia czegoś z innej tabeli zawsze można
> zrobić ładnego JOIN'a EJB-QL. Zapytania SQL generowane w ten sposób
> wyglądają znacznie lepiej niż niektóre "potworki" (ładowanie połowy
> bazy), które mogą się tworzyć przy ładowaniu całych obiektów.
Dzięki, będę musiał powalczyć z JOIN'em i tablicami. Może coś z tego
będzie.