Set czy Collection w deklaracji OneToMany

Set czy Collection w deklaracji OneToMany
P4
  • Rejestracja:ponad 10 lat
  • Ostatnio:ponad 6 lat
  • Postów:159
0

Dzień dobry, mam pytanie dotyczące deklaracji w definicji encji np. związku OneToMany

u siebie używam Set np.

Kopiuj
 @OneToMany(cascade = CascadeType.ALL, mappedBy = "idNaglowka")
    private Set<Pozycje> pozycjeSet;

na forum tym kilkakrotnie podkreślano, że tak trzeba, jednak przed wyświetleniem danych na stronie JSF w postaci DataTable zmieniam go na listę. Jest to jednak dodatkowa czynność a zależy mi na testach wydajności ? czy ma to jakieś znaczenie, czy użyć lepiej innej deklaracji np. jakiej ? ( Collection lub List )

edytowany 1x, ostatnio: Pawel412
matt_z
  • Rejestracja:około 8 lat
  • Ostatnio:ponad 7 lat
  • Postów:56
0

Hej.

W skrócie nie ma to większego znaczenia. Jeżeli chcesz listę, to możesz zamapować kolekcję jako listę i tak będzie pewnie najwydajniej. Jeżeli zamapujesz jako Collection pod spodem i tak będzie najpewniej Set.


Shalom
No no, to nie do końca tak. Bo potem ci sie trafi multiple bag fetch exception :P
KA
Nie znasz się
KE
@matt_z: to czy masz Liste, czy Set ma duze znaczenie. w zaleznosci od tego jak czesto kolekcja jest modyfikowana mozesz wybrac wydajniejsza opcje. Lista ma sporo wad zwiazanych z jej modyfikacja czego nie ma set.
matt_z
@kemot: I tak i nie. W przypadku aplikacji bazodanowych rzadko kiedy wąskim gardłem jest modyfikacja kolekcji. Wątpię, żeby tak się okazało w przypadku aplikacji o którą pytał @Pawel412. Ale oczywiście jeżeli zmierzy, że aplikacja działa wolno bo ma listy a nie sety albo na odwrót to znaczy, że tak jest. Widziałem już kilka aplikacji działających wolno lub mega wolno. Problem mapowania listy / zbioru w przypadku małych kolekcji nie był nigdy dominujący, ale oczywiście tu może okazać się inaczej.
FI
FI
  • Rejestracja:około 10 lat
  • Ostatnio:około 4 lata
  • Postów:471
1

, jesli dobre zrozumialem to roznica jest

KE
własnie miałem to dodac :)
DQ
  • Rejestracja:prawie 10 lat
  • Ostatnio:7 miesięcy
  • Postów:141
0

Polecam artykuł: https://vladmihalcea.com/2013/10/16/hibernate-facts-favoring-sets-vs-bags/ . Zgodnie z nim lista będzie szybsza.

jarekr000000
  • Rejestracja:ponad 8 lat
  • Ostatnio:około 3 godziny
  • Lokalizacja:U krasnoludów - pod górą
  • Postów:4707
0

Szybsza nie znaczy lepsza. Autor poleca Set jednak tam gdzie Set pasuje -> "correctness". Jak mamy zbiór 100 elementów to naprawdę wydajność List s Set nie ma znaczenia.
(Miałem przypadek 125 tysięcy elementów i wtedy różnice sa już bardzo widoczne - a przy niektórych zepsutych implementacjach JPA nawet bardzo. Nie ma się co przed czasem jednak martwić, a dodatkowo czytanie 125 tysięcy elementów przez JPA to też zdrowe zwykle nie jest).


jeden i pół terabajta powinno wystarczyć każdemu
P4
  • Rejestracja:ponad 10 lat
  • Ostatnio:ponad 6 lat
  • Postów:159
0

Dziękuję za odpowiedzi i pomoc.

W moim programie,testy będą miały krótkie listy danych ( w data table ) ale wielu użytkowników pracujących w tym samym momencie.

edytowany 1x, ostatnio: Pawel412
Koziołek
Moderator
  • Rejestracja:około 18 lat
  • Ostatnio:19 dni
  • Lokalizacja:Stacktrace
  • Postów:6821
0

W przypadku pracy z typowym GUI nie ma to większego znaczenia. Jednakże należy pamiętać o głównych różnicach pomiędzy Set, a List. List uwzględnia kolejność elementów oraz może zawierać duplikaty. Jeżeli nie zależy ci na żadnym z tych elementów, to należy użyć Set. Pozwala to na uniknięcie problemów z duplikatami. Jeżeli jednak zależy ci na kolejności elementów (albo chcesz mieć duplikaty co nie ma większego sensu), to wtedy należy użyć List oraz doposażyć encje w @OrderBy.


Sięgam tam, gdzie wzrok nie sięga… a tam NullPointerException
P4
  • Rejestracja:ponad 10 lat
  • Ostatnio:ponad 6 lat
  • Postów:159
0

dzięki

edytowany 2x, ostatnio: Pawel412

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.