Mapping JPA + jOOQ

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?

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.

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?

Przede wszystkim: co chcesz osiągnąć?

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.

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

@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();
            }
        });
    }

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

scibi92 napisał(a):

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

Kopiuj

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

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.

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

@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.

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?

@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.