JPA+hibernate mapowanie wiele-do-wielu
kamiseq
zakladajac że mam 2 entity Version oraz Element ktore sa polaczone
poprzez 3-ci entity ElementCfg, co odpowiada tabelom Versions,
ElementCfgs, Elements. (taką strukture zastałem na bazie i raczej jej
nie zmienie. zresztą sama struktura raczej mi nie przeszkadza)
raz utowrzony element moze byc podlaczony do wielu wersji ale nie
istnieje samodzielnie. tak wiec przegladanie obiektow zawsze odbywa
sie poprzez wskazanie odpowiedniej wersji.
tak wiec zastosowałem mapowanie wiele do wielu. Version zawiera
kolekcje(OneToMany) wszystkich ElementCfg polaczonych z ta wersją.
ElementCfg ma złożony klucz podstawowy wskazujązcy na id_version i
id_element, także posiada referencje na obiekt Version(ManyToOne) oraz
Element(ManyToOne). i na koniec Element zawiera kolekcje(OneToMany)
wszystkich ElementCfg związanych z tym elementem. wszystko działa bez
zarzutu. pobieram obiekt wersji, dociągam kolekcje ElementCfg a dla
kazdego obiektu ElementCfg moge pobrac obiekt Element.
no i teraz zaczyna sie moj problem. patrzac na ten prosty model ze
strony aplikacji -widoku wersji- na tym co mi zalezy to : wersja i
skonfigurowane elementy w tej wersji czyli polaczone obiekty Element
(nazwa elementu, wlasciciel) + ElementCfg(data waznowsci, ilosc)
jednoczesnie. uzytkownik nic specjalnego nie wyczyta z samej kolekcji
ElementCfg wyswietlonej w tabeli- musi miec od razu wyswietlona
informacje o podlaczonym elemencie. zeby to osiagnac musialbym po
stronie javy 1)utworzyc nowa kolekcje, 2)przelecieć wszystkie obiekty
ElementCfg i dociagnac obiekt Element po czym to 3)wszystko umiescic w
nowym obiekcie nowego typu np ElementNCfg.
czesciowo poradziłem sobie uzywajac zapytania w JPQL [select new
myapp.entity.ElementNCfg(c.element, c) from Version v, in
(v.elementCfgSet) c where v.idVersion = :idVersion].
MOJE PYTANIE BRZMI:
czy mozna to zrobic ladniej na poziomie samego mapowania entity?????
tzn czy Version mogłoby odrazu miec zmapowaną kolekcje obiektow typu
ElementNCfg co w efekcie by sie sprowadziło do posiadania 3 entity
Version, ElementNCfg, Element, które to mapowały by sie na oryginalne
tabele Versions, ElementCfgs, Elements.
dodatkowo czy mozna wskazac aby JPA mapowała w Element kolekcje
obiektów typu Version zamiast ElementCfg???
pozdrawiam
kamiseq
Matt Z
> dodatkowo czy mozna wskazac aby JPA mapowa�a w Element kolekcje
> obiekt�w typu Version zamiast ElementCfg???
@ManyToMany?
Czyta�e� dokumentacj�?
--
pozdrawiam
Mateusz
http://na-jawie.blogspot.com
http://sites.google.com/site/pudelekeclipseplugin/
kamiseq
> Czytałeś dokumentację?
kiedys...
tylko to jest czesc mojego problemu. co jesli zastosuje ManyToMany dla
Element-Version (ktora bedize przechodzila przez tabele ElementCfg), a
z drugiej strony OneToMany Version-ElementCfg-Element. czy to sie
jakos nie pochrzani przy zapisie update-cie? troche brak mi tutaj
doswiadczenia czy intuicji.
Tomek Nurkiewicz
>> Czyta�e� dokumentacj�?
>
> tylko to jest czesc mojego problemu. co jesli zastosuje ManyToMany dla
> Element-Version (ktora bedize przechodzila przez tabele ElementCfg), a
> z drugiej strony OneToMany Version-ElementCfg-Element. czy to sie
> jakos nie pochrzani przy zapisie update-cie? troche brak mi tutaj
> doswiadczenia czy intuicji.
Nie istnieje taka konstrukcja jak wiele-do-wielu po jednej stronie i
jeden-do-wielu po drugiej stronie zwi�zku. Nie tylko w JPA, ale w og�le
w relacyjnych bazach danych. Je�li masz tabel� intersekcji z *dok�adnie*
[*] dwoma kolumnami - kluczami obcymi na obie tabele bior�ce udzia� w
zwi�zku - to jest po prostu zwi�zek wiele-do-wielu.
Je�li potrzebujesz czego� bardziej finezyjnego, ukryj implementacj� w
DAO a zwracaj u�ytkownikowi jakie� bardziej abstrakcyjne byty. Bazy nie
przeskoczysz.
[*] Je�li tabela intersekcji ma jakiekolwiek inne kolumny, to
najprawdopodobniej coďż˝ jest nie tak sam z samym projektem bazy. Zwykle
oznacza to, �e mamy do czynienia z dodatkowymi cechami zwi�zku, np.
'ilo��' w zwi�zku Zam�wienie-Towar. Nawet sztuczny klucz g��wny (a nie
z�o�ony z kluczy obcych) sugeruje "database-smell".
pozdrowienia
--
Tomek Nurkiewicz
http://nurkiewicz.blogspot.com
kamiseq
wrote:
> >> @ManyToMany?
> >> Czytałeś dokumentację?
>
> > kiedys...
> > tylko to jest czesc mojego problemu. co jesli zastosuje ManyToMany dla
> > Element-Version (ktora bedize przechodzila przez tabele ElementCfg), a
> > z drugiej strony OneToMany Version-ElementCfg-Element. czy to sie
> > jakos nie pochrzani przy zapisie update-cie? troche brak mi tutaj
> > doswiadczenia czy intuicji.
>
> Nie istnieje taka konstrukcja jak wiele-do-wielu po jednej stronie i
> w relacyjnych bazach danych. Jeśli masz tabelę intersekcji z *dokładnie*
> [*] dwoma kolumnami - kluczami obcymi na obie tabele biorące udział w
> związku - to jest po prostu związek wiele-do-wielu.
>
> Jeśli potrzebujesz czegoś bardziej finezyjnego, ukryj implementację w
> DAO a zwracaj użytkownikowi jakieś bardziej abstrakcyjne byty. Bazy nie
> przeskoczysz.
>
> [*] Jeśli tabela intersekcji ma jakiekolwiek inne kolumny, to
> najprawdopodobniej coś jest nie tak sam z samym projektem bazy. Zwykle
> oznacza to, że mamy do czynienia z dodatkowymi cechami związku, np.
> 'ilość' w związku Zamówienie-Towar. Nawet sztuczny klucz główny (a nie
> złożony z kluczy obcych) sugeruje "database-smell".
czyli tak jak to zrobilem jest ok i lepiej nie bedzie?
tzn OneToMany + ManyToOne + OneToMany i odpowiednie zapytanie ktore
zwraca nowy typ powstały z złaczenia dwoch encji
Jarek
> strony aplikacji -widoku wersji- na tym co mi zalezy to : wersja i
> skonfigurowane elementy w tej wersji czyli polaczone obiekty Element
> (nazwa elementu, wlasciciel) + ElementCfg(data waznowsci, ilosc)
> jednoczesnie. uzytkownik nic specjalnego nie wyczyta z samej kolekcji
> ElementCfg wyswietlonej w tabeli- musi miec od razu wyswietlona
> informacje o podlaczonym elemencie. zeby to osiagnac musialbym po
> ElementCfg i dociagnac obiekt Element po czym to 3)wszystko umiescic w
> nowym obiekcie nowego typu np ElementNCfg.
>
> myapp.entity.ElementNCfg(c.element, c) from Version v, in
> (v.elementCfgSet) c where v.idVersion = :idVersion].
A nie mo�esz zrobi� czego� takiego:
select v from Version v left join fetch v.elementCfgSet.element where
v.idVersion = :idVersion
albo podobnie?
Pozdrawiam
Jarek
kamiseq
>
> select v from Version v left join fetch v.elementCfgSet.element where
> v.idVersion = :idVersion
ale przeciez tutaj wyciagasz wersjie dla konkretnego Id a ja
potrzebuje wszystkie elementy wraz z konfiguracja dla danej wersji..