Mapping JPA + jOOQ

0

Cześć,
chcę zapytać czy użycie JPA jako ORM(tylko), natomiast query, zarządzanie transakcjami etc. w jOOQ ma sens? Jeśli tak to jak to dobrze rozdzielić - po prostu DAO'sy pisać w jOOQ i tyle? Ono zrozumie moje mapowania typu @OneToMany? Czy jakieś inne, lepsze wyjście z tego jest?

1

JOOQ (prawie) nic za Ciebie nie zrobi sam. Piszesz w nim sqle i dostajesz wynik w postaci takiej jak mniej więcej zwraca baza danych (w postaci kolejnych rekordów). Można sobie ułatwić trochę prace używając modelmappera, ale trzeba mu pomóc w jakichś bardziej złożonych mapowaniach.

0

Rozumiem. Do tej pory do klejenia SQL'ek używałem CriteriaAPI (tak jak w pracy), ale dowiedziałem się jakiś czas temu o jOOQ i postanowiłem w końcu spróbować. Czyli czy uda mi się robić to w taki sposób:
ENCJE JPA
Zapytania SQL, transakcje itp. w jOOQ.

Czy to zadziała czy muszę tutaj robić jakieś magie jeśli moja encja to nie jest czyste POJO bez użycia JPA?

0

Przede wszystkim: co chcesz osiągnąć?

0

Ogólnie to chcę mapować sobie wszystkie relacje, tabele, pola z moich POJO do bazy danych. Natomiast wszelkie pozostałe operacje na tej bazie chcę pozostawić sobie, a nie oddawać władzy nad tym np. Springowi i słynnemu @Transactional np.

0

Dobrze, to zapytam inaczej: jak wy widzicie użycie jOOQ? Jak dobrze w Javie zajmować się mapowaniem POJO -> TABELA, jak zajmować się transakcjami?

0

@weiss: ale w Springu nie musisz używać @Transactional, jest jeszcze...


public Object someServiceMethod() {
        return transactionTemplate.execute(new TransactionCallback() {
            // the code in this method executes in a transactional context
            public Object doInTransaction(TransactionStatus status) {
                updateOperation1();
                return resultOfUpdateOperation2();
            }
        });
    }

0

Ja używam do pisania sqli i potem na POJO mapuje przez ModelMappera. Przy niektórych rzeczach (nie wiem czemu, ale czasem gubi się z enumem) pomagam ręcznie

0
scibi92 napisał(a):

@weiss: ale w Springu nie musisz używać @Transactional, jest jeszcze...


public Object someServiceMethod() {
        return transactionTemplate.execute(new TransactionCallback() {
            // the code in this method executes in a transactional context
            public Object doInTransaction(TransactionStatus status) {
                updateOperation1();
                return resultOfUpdateOperation2();
            }
        });
    }

@danek czyli do mapowania Result -> POJO ModelMapper, a czasami dodajesz coś od siebie, rozumie. Spróbuję coś wymyślić w takim razie

2

Zaletą tych bibliotek. (JOOQ / QueryDSL) jest to, że możesz sobie wygenerować fluent API na podstawie bazy. Szczególnie swietnie to działa z narzedziami do wersjonowania i zarządzania schematem. Przykładowo JOOQ + Liquibase. Piszesz tylko nazwy kolumn w swoim skrypcie SQL ewentualnie pliku liquibase i potem nie musisz wykonywać małpiej roboty z przeklepywaniem tego do kodu.

Zalety JOOQ i QueryDSL

  • proste i lekkie biblioteki
  • generują API, odwalając ciężką robotę
  • type safe query (szczególnie użyteczne przy joinach i grupowaniach)

Wady JOOQ i QueryDSL

  • Relacje jeden do wielu / wiele do wielu musisz ogarniać sam. Co przy systemach nie CRUDowych może być zaletą.

Wady JOOQ:

  • płatne dla niektórych baz np, Oracle. Cena jest dość niska, więc każdą firmę powinno być stać.

Wady QueryDSL

  • nie rozwijane mniej więcej od 2016 roku.
0

Co znaczy, że przy aplikacjach niecrudowych to zaletą? Wtedy takie relacje się samemu określa jakoś? (jak?) Czy po prostu relacji nie ma?

0

@weiss: Jak masz 100 encji, każda poannotowana magicznymi adnotacjami to kończy się jednym wielkim ściąganiem całej bazy i modlitwami do Boga ORM, że cache Hibernate ogarnie. Jak nieogarnie to pół roku zamiast dostarczać wartość biznesową czytasz blog Vlad Mihalcea https://vladmihalcea.com/

Gdy mamy do czynienia z cięzkimi operacjami biznesowymi to zwykle lepiej według mnie po prostu napisać tego inserta. I nie mieć w logice biznesowej magii. SQL na prawdę jest elegancką technologią. Ostatecznie i tak osiągniesz sukces i będziesz miał miliony klientów i przejdziesz na DynamoDB :P

Hibernate według mnie ma sens tylko ze Spring Data by szybko tworzyć CRUDy.

0

Rozumiem, ale na poziomie bazy mamy ustalone te relacje czy po prostu np. są pola, które trzymają id'ki/listy id'ków do encji połączonych?

0

@nie100sowny: o ile nie do końca przepadam za JPA to o tyle nie sądze żeby korzystanie z ORMów było całkowicie złe. Można na przykład ORMy wykorzystac do insertów /updatetów/deletów a natywne SQL albo JOOQ do selectów.

1 użytkowników online, w tym zalogowanych: 0, gości: 1