Hej, wiem, że spring ma wsparcie dla Vavra jeśli chodzi o zwracane typy z JpaRepository itd, a co z polami w encjach, embeddablach ? Jak mam @ElementCollection np to to już nie zadziała. Są jakieś obejścia ?
0
0
Takie coś jest bez sensu, javove kolekcje są o wiele szybsze. Vavrowe używaj sobie w jakiejś logice
1
Przeczytaj wątek https://github.com/vavr-io/vavr/issues/2022
Czy pomysł jest bez sensu? Nie powiedziałbym. W aplikacji, w której w encjach jest logika biznesowa może mieć sens, żeby konwersję „schować” na poziomie ORM. Oczywiście bardziej elastycznie byłoby przemapować się z encji JPA na encję domenową i tam już hulaj dusza.
0
Wydaje mi się że to zly pomysł.
Dlaczego?
Vavrowe kolejkcje = immutowalność. Generalnie cały VAVR pewnie tak działa, bo takie są jego założenia.
No i teraz mamy problem tego typu, że klasy odpowiedzialne za Encje będziemy poddawać non stop jakimś obróbkom, więc sami sobie robimy pod górkę. Chcesz dodać nowy element do relacji? JEB nowa lista w pamięci.
Wydaje mi się że jeżeli chodzi o jakiś performance to z tymi kolekcjami VAVRowimi może być lipa.
(Nie wiem czy to dokładnie tak działa, może mnie ktos poprawić)
- Mapujesz encje podczas selecta.
- Mapujesz lista javovą do listy vavrowej (drugi raz relokujesz pamięć na to samo)
- Dodajesz/usuwasz element z listy vavrowej (tworzysz kolejną kopie listy vavrowej - w końcu immutable)
- Chcesz to zapisać na bazie -> mapujesz liste vavrową na Javovą i persist.
Ja bym się zastanowił 2x czy potrzebujesz te vavrowe kolekcje.
1
Najlepszym obejściem jest nie stosowanie JPA :D
A jak już musisz to trzeba stosować po prostu oddzielne encje JPA i encje biznesowe, na szczęscie w przypadku VAVRa to jest to w miarę wygodne :)
0
Dzięki za odpowiedzi.
Generalnie coś średnio mi działa Koltin z tym JPA, może dlatego, że użyłem mavena zamiast gradla.
Ale mam dwa poważne problemy:
- Przy użyciu kolekcji
MutableSetw encji jpa z mapowaniem@ElementCollectionto jak dodaję itemek do seta, to najpierw leci delete na tabele kolekcji, a potem insert po insercie. WTF ? - Zupgradowałem się do najnowszego kotlina ostatnio i wstrzykiwanie przy użyciu
@Beantak średnio działa, bo i tak mam nulle w zależnościach w serwisach/fasadach.
Co zamiast JPA ewentualnie do Spring Boota z Koltinem ? Projekt mam od dawna, więc spring boota wywalał nie będę, a to i tak MVP.
1
O panie...
-
https://vladmihalcea.com/how-to-optimize-unidirectional-collections-with-jpa-and-hibernate/
-
Wybór Maven/Gradle z punktu widzenia Kotlina nie ma znaczenia, chyba że chodzi o KotlinDSL dla Gradla. To samo dotyczy JPA. Możesz budować nawet Antem.
-
Co to znaczy, że wstrzykiwanie średnio działa? Wstrzykujesz przez konstruktor (jeśli nie to zacznij)? Jaki błąd leci?
-
Z takim podejściem nic Ci nie będzie nigdy działać. Zdiagnozuj problem i popraw zamiast zmienić technologię.
0
ad. 1 Panie, zetknąłem się już z tymi rzeczami kilka lat temu. Oglądałem talka J.Kubryńskiego odnośnie JPA. Przede wszystkim ja nie używam listy, tylko seta, a dokładniej MutableSet<T>. Czy w secie nie powinno być z tym problemu skoro i tak nie potrzebuję kolejności ? @OrderColumn wydaje się w ogóle na MutableSet<T> nie mieć efektu.
ad 2 Ok
ad. 3 Tak, wstrzykuję przez konstruktor, to chyba jasne :D Czytałeś dokładnie co napisałem ? Skoro wstrzykuję poprzez adnotację @Bean to znaczy, że wstrzykuję poprzez konstruktor no nie ? Leci null pointer, bo zależności w serwisach są nullowe.
0
Nie zrozumiałem ostatniego pytania, ale poczytaj tutaj: https://vladmihalcea.com/hibernate-facts-favoring-sets-vs-bags/