Mapping JPA + jOOQ

Odpowiedz Nowy wątek
2019-07-13 18:31
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?

Pozostało 580 znaków

2019-07-13 19:14
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.


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.

Pozostało 580 znaków

2019-07-13 19:17
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?

A ja lubię JDBI, podobne rozwiązanie ... - AnyKtokolwiek 2019-07-13 22:30

Pozostało 580 znaków

2019-07-13 19:51
0

Przede wszystkim: co chcesz osiągnąć?


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.

Pozostało 580 znaków

2019-07-13 20:12
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.

Nadal nie jest to jasno podana koncepcja. Szczególnie oderwanie transakcji od JPA trudno mi sobie wyobrazić - AnyKtokolwiek 2019-07-13 22:19

Pozostało 580 znaków

2019-07-13 22:27
0

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

Pozostało 580 znaków

2019-07-14 01:03
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();
            }
        });
    }

Nie pomagam przez PM. Pytania zadaje się na forum.

Pozostało 580 znaków

2019-07-14 10:47
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


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.

Pozostało 580 znaków

2019-07-14 12:52
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

Pozostało 580 znaków

2019-07-15 17:21
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.

"Gdy się nie wie, co się robi, to się dzieją takie rzeczy, że się nie wie, co się dzieje"


Pozostało 580 znaków

2019-07-16 16:30
0

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

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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