etichetă: SqlResultSetMapping

frumusețea se află în ochiul privitorului. Deci, nu „ușura”:

Thorben scrie articole foarte bune și utile despre JPA și a început recent o serie excelentă despre noile caracteristici ale JPA 2.1. Printre care: maparea setului de rezultate. Este posibil să cunoașteți maparea setului de rezultate de pe site-uri web precum CTMMC sau annotatiomania.com. putem rezuma această procedură de mapare după cum urmează:

a) definiți maparea

@SqlResultSetMapping( name = "BookAuthorMapping", entities = { @EntityResult( entityClass = Book.class, fields = { @FieldResult(name = "id", column = "id"), @FieldResult(name = "title", column = "title"), @FieldResult(name = "author", column = "author_id"), @FieldResult(name = "version", column = "version")}), @EntityResult( entityClass = Author.class, fields = { @FieldResult(name = "id", column = "authorId"), @FieldResult(name = "firstName", column = "firstName"), @FieldResult(name = "lastName", column = "lastName"), @FieldResult(name = "version", column = "authorVersion")})})

maparea de mai sus este mai degrabă directă. Specifică modul în care coloanele bazei de date ar trebui să fie mapate la câmpurile entității și la entitățile în ansamblu. Apoi dați acestei mapări un nume ("BookAuthorMapping"), pe care îl puteți reutiliza apoi în aplicația dvs., de ex.cu interogări JPA native.

îmi place în mod special faptul că Thorben scrie apoi:

dacă nu doriți să adăugați un astfel de bloc imens de adnotări entității dvs., puteți defini, de asemenea, maparea într-un fișier XML

… așadar, ne-am întors la înlocuirea blocurilor uriașe de adnotări cu blocuri uriașe de XML – o tehnică pe care mulți dintre noi am vrut să o evităm folosind adnotări… :- )

B) aplicați maparea

odată ce maparea a fost definită static pe un tip Java, puteți prelua acele entități aplicând cele de mai sus BookAuthorMapping

List<Object> results = this.em.createNativeQuery( "SELECT b.id, b.title, b.author_id, b.version, " + " a.id as authorId, a.firstName, a.lastName, " + " a.version as authorVersion " + "FROM Book b " + "JOIN Author a ON b.author_id = a.id", "BookAuthorMapping").getResultList();results.stream().forEach((record) -> { Book book = (Book)record; Author author = (Author)record;});

observați cum încă mai trebuie să vă amintiți Book și Author tipuri și exprimate în mod explicit ca nici o informație de tip verificabile este într-adevăr atașat la nimic.

definiția „complex”

acum, articolul susține că acest lucru este de cartografiere „complex”, și fără îndoială, aș fi de acord. Această interogare foarte simplă, cu doar o simplă asociere, declanșează deja o astfel de mizerie de adnotare dacă doriți să vă mapați cu adevărat entitățile prin JPA. Nu doriți să vedeți adnotările de cartografiere ale lui Thorben, odată ce interogările devin puțin mai complexe. Și amintiți-vă, @SqlResultSetMapping este despre cartografiere (nativ!) Rezultate SQL, deci nu mai suntem în teren obiect-grafic-persistență, suntem în teren SQL, în cazul în care preluarea în vrac, denormalizing, agregarea, și alte chestii SQL „fantezie” este rege.

problema este aici:

Java 5 a introdus adnotări. Adnotările au fost inițial destinate a fi utilizate ca „modificatori artificiali”, adică lucruri precum static, final, protected (destul de interesant, Ceylon cunoaște doar adnotări, fără modificatori). Acest lucru are sens. Designerii de limbaj Java ar putea introduce noi modificatori / ” cuvinte cheie „fără a rupe codul existent – deoarece cuvintele cheie” reale ” sunt cuvinte rezervate, care sunt greu de introdus într-o limbă. Îți amintești enum?

deci, cazuri bune de utilizare pentru adnotări (și există doar câteva) sunt:

• @Override
• @Deprecated (deși, un atribut comentariu ar fi fost fantezie)
• @FunctionalInterface

JPA (și alte API-uri Java EE, precum și Spring) au devenit complet nebunești cu privire la utilizarea adnotărilor. Repetă după mine:

nici o limbă @Before sau @After Java abuzat vreodată adnotări la fel de mult ca Java

(ideea @Before / @ After a fost a lui lennoff, pe reddit)

există un puternic d inktiftvu în mine când citesc cele de mai sus. Îți amintești următoarele?

nicio limbă înainte sau după Java a abuzat vreodată de excepții verificate la fel de mult ca Java

cu toții vom regreta profund adnotările Java până în 2020.

adnotările sunt o verucă mare în sistemul de tip Java. Au o utilizare justificată extrem de limitată și ceea ce facem dezvoltatorii Java Enterprise în aceste zile nu este absolut în limitele „justificate”. Le abuzăm pentru configurare pentru lucruri pentru care ar trebui să scriem cod.

Iată cum ar rula aceeași interogare cu jOOQ (sau orice alt API care foloseste generice și tipul de siguranță pentru SQL):

Book b = BOOK.as("b");Author a = AUTHOR.as("a");DSL.using(configuration) .select(b.ID, b.TITLE, b.AUTHOR_ID, b.VERSION, a.ID, a.FIRST_NAME, a.LAST_NAME, a.VERSION) .from(b) .join(a).on(b.AUTHOR_ID.eq(a.ID)) .fetch() .forEach(record -> { BookRecord book = record.into(b); AuthorRecord author = record.into(a); });

acest exemplu combină atât adnotările JPA 2.1, cât și interogările. Toate informațiile meta despre „entități” proiectate sunt deja conținute în interogare și, prin urmare, în Result care este produs de fetch() metodă. Dar nu contează cu adevărat, ideea este că această expresie lambda…

record -> { BookRecord book = record.into(b); AuthorRecord author = record.into(a);}

… poate fi orice vrei! La fel ca exemplele mai sofisticate pe care le-am arătat în postările anterioare de pe blog:

• nu mai este nevoie de ORMs
• transformați datele SQL în diagrame folosind jOOQ și JavaFX

maparea poate fi definită ad-hoc, din mers, folosind funcții. Funcțiile sunt mapoarele ideale, deoarece iau o intrare, produc o ieșire și sunt complet apatride. Și cel mai bun lucru despre funcțiile din Java 8 este că sunt compilate de compilatorul Java și pot fi folosite pentru a verifica maparea. Și puteți atribui funcții obiectelor, ceea ce vă permite să reutilizați funcțiile, atunci când un algoritm de mapare dat poate fi utilizat de mai multe ori.

de fapt, clauza SQL SELECT în sine este o astfel de funcție. O funcție care transformă tupluri de intrare / rânduri în tupluri de ieșire / rânduri, și vă puteți adapta această funcție pe zbor folosind expresii suplimentare.

nu există absolut nici o modalitate de a scrie-verifica nimic în JPA 2.1 instrucțiunea SQL nativ anterior și @SqlResultSetMapping exemplu. Imaginați-vă schimbarea unui nume de coloană:

List<Object> results = this.em.createNativeQuery( "SELECT b.id, b.title as book_title, " + " b.author_id, b.version, " + " a.id as authorId, a.firstName, a.lastName, " + " a.version as authorVersion " + "FROM Book b " + "JOIN Author a ON b.author_id = a.id", "BookAuthorMapping").getResultList();

ai observat diferența? Coloana b.titlea fost redenumită în book_title. Într-un șir SQL. Care explodează în timpul rulării! Cum să vă amintiți că trebuie să vă adaptați

@FieldResult(name = "title", column = "title")

… pentru a fi

@FieldResult(name = "title", column = "book_title")

în schimb, cum să vă amintiți că odată ce redenumiți column în @FieldResult, va trebui să mergeți să verificați oriunde este utilizat acest "BookAuthorMapping" și să schimbați și numele coloanelor din acele interogări.

@SqlResultSetMapping( name = "BookAuthorMapping", ...)

adnotările sunt rele

puteți sau nu să fiți de acord cu unele dintre cele de mai sus. S-ar putea sau nu să vă placă jOOQ ca alternativă la JPA, este perfect în regulă. Dar este foarte greu să nu fiți de acord cu faptul că:

• Java 5 a introdus adnotări foarte utile
• Java EE / Spring a abuzat puternic de aceste adnotări pentru a înlocui XML
• acum avem un sistem de tip univers paralel în Java
• acest sistem de tip univers paralel este complet inutil, deoarece compilatorul nu îl poate introspect
• Java SE 8 introduce programarea funcțională și o mulțime de inferențe de tip
• java se 9-10 va introduce mai multe caracteristici de limbaj minunat
• acum devine clar că ceea ce a fost de configurare (XML sau adnotări) ar fi trebuit să fie cod în primul rând
• JPA 2.1 a devenit noul EJB 2.0: învechit

așa cum am spus. Greu de dezacord. Sau cu alte cuvinte:

codul este mult mai bine la exprimarea algoritmi decât de configurare

l-am întâlnit personal pe Thorben de mai multe ori la conferințe. Acest declama aici nu a fost menit personal, Thorben: -) articole despre JPA sunt foarte interesante. Dacă cititorii acestui articol folosesc JPA, vă rugăm să consultați blogul lui Thorben: http://www.thoughts-on-java.org.

între timp, mi-ar plăcea să-l nominalizez pe Thorben pentru titlul respectat „Adnotatiomanul anului 2015”