🚀 go-pugleaf

W dniu 2011-10-15 16:52, Jacek Czerwinski pisze:
> Na rozwijanym projekcie mam pytanie z JPA2.
>
> jest niewielka "perzystentna" hierarcha klas koncepcyjnie umieśćmy ją z
> lewej strony.
> @Entity
> @Table(name = "tab1")
> @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
> public class Information1 extends Information0 {...
>
> Dwie-trzy inne podobne. Ich/jej przodek ma relację
>
> @MappedSuperclass
> public abstract class Information0 {
>
> @ManyToMany(cascade = CascadeType.PERSIST)
> @JoinTable(name = "tab3", joinColumns = @JoinColumn(name = "item_ID"),
> inverseJoinColumns = @JoinColumn(name = "tag_ID"))
> @ElementCollection
> private Set<InformationRight > tags = new HashSet<InformationRight >();
>
>
> Klasa InformationRight nie ma dziedziczeń.
>
> generuje się tabela pośrednia z dwoma kluczami-integerami. Mi w niej,
> jakbym miał ręcznie kodować, brakuje np. rzeczywistej klasy obiektu z
> lewej. W konsekwencji kwerendy 'od prawej'
>
> select InformationRight r join Information4 l where ....
> l.class=Information4 and ...
>
> będą niepotrzebnie kosztowne, dobrze myslę? czy też będzie się to
> optymalizowało? Czy to w ogóle będzie legalne tak pisać z Information4 ?
>
> Kwerenda wymyślona, nie implementowana jeszcze, czy mam się wrócić i coś
> zmienić? Dręczy mnie brak jakiejś klasyfikacji w tabeli pośredniej.
>
> Nie potrafię tego z siebie wydukać po angielsku, więc i googlanie nie
> idzie.
Nie bardzo rozumiem, w jakim kierunku zmierzasz, ale imo jak coś jest 
zamapowanym set'em, to nie dobieramy się do tego przez joiny, ale raczej
'po obiektowemu', czyli: "select tags from Information4".
Zdaje się, że Hibernatowym hql'u takie coś spokojnie pójdzie.

W dniu 2011-10-15 16:52, Jacek Czerwinski pisze:
> Na rozwijanym projekcie mam pytanie z JPA2.
>
> jest niewielka "perzystentna" hierarcha klas koncepcyjnie umieśćmy ją z
> lewej strony.
> @Entity
> @Table(name = "tab1")
> @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
> public class Information1 extends Information0 {...
>
> Dwie-trzy inne podobne. Ich/jej przodek ma relację
>
> @MappedSuperclass
> public abstract class Information0 {
>
> @ManyToMany(cascade = CascadeType.PERSIST)
> @JoinTable(name = "tab3", joinColumns = @JoinColumn(name = "item_ID"),
> inverseJoinColumns = @JoinColumn(name = "tag_ID"))
> @ElementCollection
> private Set<InformationRight > tags = new HashSet<InformationRight >();
>
>
> Klasa InformationRight nie ma dziedziczeń.
>
> generuje się tabela pośrednia z dwoma kluczami-integerami. Mi w niej,
> jakbym miał ręcznie kodować, brakuje np. rzeczywistej klasy obiektu z
> lewej. W konsekwencji kwerendy 'od prawej'
>
> select InformationRight r join Information4 l where ....
> l.class=Information4 and ...
>
> będą niepotrzebnie kosztowne, dobrze myslę? czy też będzie się to
> optymalizowało? Czy to w ogóle będzie legalne tak pisać z Information4 ?
>
> Kwerenda wymyślona, nie implementowana jeszcze, czy mam się wrócić i coś
> zmienić? Dręczy mnie brak jakiejś klasyfikacji w tabeli pośredniej.
>
> Nie potrafię tego z siebie wydukać po angielsku, więc i googlanie nie
> idzie.

Nie wiem, czy dobrze rozumiem pytanie, ale imo do normalnie zamapowanego
set'a nie dobieramy sięprzez joina, ale 'obiektowo',
czyli 'select tags from Information4'
Czy moja odpowiedź idzie w pożądanym kierunku ? :)

Jacek Czerwinski <x@y.z.pl> napisał(a): 

> Na rozwijanym projekcie mam pytanie z JPA2.
> 
> jest niewielka "perzystentna" hierarcha klas koncepcyjnie umieśćmy ją z 
> lewej strony.
> @Entity
> @Table(name = "tab1")
> @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
> public class Information1 extends Information0  {...
> 
> Dwie-trzy inne podobne. Ich/jej przodek ma relację
> 
> @MappedSuperclass
> public abstract class Information0   {
> 
> 	@ManyToMany(cascade = CascadeType.PERSIST)
> 	@JoinTable(name = "tab3",	joinColumns = @JoinColumn(name = "item_ID"), 
>   inverseJoinColumns = @JoinColumn(name = "tag_ID"))
> 	@ElementCollection
> 	private Set<InformationRight  > tags = new HashSet<InformationRight  >();
> 
> 
> Klasa InformationRight  nie ma dziedziczeń.
> 
> generuje się tabela pośrednia z dwoma kluczami-integerami. Mi w niej, 
> jakbym miał ręcznie kodować, brakuje np. rzeczywistej klasy obiektu z 
> lewej. W konsekwencji kwerendy 'od prawej'
> 
> select InformationRight  r join Information4 l where .... 
> l.class=Information4 and ...
> 
> będą niepotrzebnie kosztowne, dobrze myslę? czy też będzie się to 
> optymalizowało? Czy to w ogóle będzie legalne tak pisać z Information4 ?
> 
> Kwerenda wymyślona, nie implementowana jeszcze, czy mam się wrócić i coś 
> zmienić? Dręczy mnie brak jakiejś klasyfikacji w tabeli pośredniej.
> 
> Nie potrafię tego z siebie wydukać po angielsku, więc i googlanie nie idzie.
> 
> 
Nie wszystko rozumiem ale... wykombinowalem ze masz baze klase i kilka
sub-klas. Ta baza ma ManyToMany polaczenie z inna klasa.
Jesli mam racje to pare uwag:
Przy  ManyToMany zawsze sie generuje posrednia tablica z kluczami
macierzystych tablic. Takie koncatynated key. W javie kazda z tych klas ma
kolekcje (set albo list) tej drugiej klasy. moze przyklad: jest wiele
projektow i wielu programerow i moga one byc w roznej kombinacji. Programer ma
kilka objektow typu project i kazdy projekt moze miec kilku programerow.
Mowiac prosciej w database potrzebujesz 3 objektow w javie tylko 2.

Wybierajac TABLE_PER_CLASS wystawiasz sie na spore niebezpieczenstwo, bo
bedziesz kreowal dodatkowa tablice na kazda sub-klase. Wtedy majac scenariusz 
baza + 3 sub-klasy + inna klasa = 7 tablic
wybierajac join bedziesz mial = 5 tablic
wybierajac single table dostaniesz = 3 tablice

Mam nadzieje ze wyrazm sie prosto, przykro mi ale moj komputerowy polski jest
ograniczony. 
r,



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