Mapping JPA + jOOQ

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

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?