címke: SqlResultSetMapping

a szépség a szemlélő szemében rejlik. Tehát nem “könnyű”:

Thorben nagyon jó és hasznos cikkeket ír a JPA – ról, és nemrégiben egy kiváló sorozatot indított a JPA 2.1 új funkcióiról. Amelyek között: eredményhalmaz-leképezés. Lehet, hogy ismeri az eredményhalmaz leképezését olyan webhelyekről, mint a CTMMC, vagy annotatiomania.com. ezt a leképezési eljárást a következőképpen foglalhatjuk össze:

a) határozza meg a leképezést

@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")})})

a fenti leképezés meglehetősen egyenes. Meghatározza, hogy az adatbázis-oszlopokat hogyan kell leképezni az entitásmezőkre és az entitások egészére. Ezután nevet ad ennek a leképezésnek ("BookAuthorMapping"), amelyet aztán újra felhasználhat az alkalmazásban, például natív JPA lekérdezésekkel.

kifejezetten szeretem azt a tényt, hogy Thorben akkor írja:

ha nem szeretne ilyen hatalmas annotációs blokkot hozzáadni az entitáshoz, akkor a leképezést XML fájlban is meghatározhatja

… így, visszatértünk a hatalmas annotációs blokkok helyettesítésére hatalmas XML-blokkokkal – ez a technika, amelyet sokan el akartunk kerülni a kommentárok használatával… :- )

b) alkalmazza a leképezést

miután a leképezést statikusan meghatározták valamilyen Java típuson, a fentiek alkalmazásával lekérheti ezeket az entitásokat 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;});

figyeld meg, hogyan kell még emlékezni a Book és Author típusokra, és a cast-et kifejezetten, mivel nincs ellenőrizhető típusú információ, ami valóban csatolva lenne bármihez.

a “komplex”meghatározása

most a cikk azt állítja, hogy ez “komplex” feltérképezés, és kétségtelenül egyetértek. Ez a nagyon egyszerű lekérdezés, csak egy egyszerű csatlakozással, már ilyen annotációs rendetlenséget vált ki, ha valóban meg akarja térképezni az entitásokat a JPA-n keresztül. Nem akarja látni Thorben leképezési kommentárjait, ha a lekérdezések kissé összetettebbé válnak. És ne feledd, @SqlResultSetMapping a térképezésről szól (natív!) SQL eredmények, tehát már nem az objektum-gráf-perzisztencia földön vagyunk, hanem az SQL földön, ahol a tömeges Lekérés, denormalizálás, összesítés és más “divatos” SQL dolgok a király.

a probléma itt van:

a Java 5 annotációkat vezetett be. A kommentárokat eredetileg “mesterséges módosítóként” szánták, azaz olyan dolgok, mint static, final, protected (érdekes módon Ceylon csak kommentárokat ismer, módosítókat nem). Ennek van értelme. A Java nyelvtervezők új módosítókat / “kulcsszavakat” vezethetnek be a meglévő kód feltörése nélkül – mert a “valódi” kulcsszavak fenntartott szavak, amelyeket nehéz bevezetni egy nyelven. Emlékszel enum?

tehát a kommentárok jó Felhasználási esetei (és csak kevés) vannak:

• @Override
• @Deprecated (habár, egy megjegyzés attribútum divatos lett volna)
• @FunctionalInterface

a JPA (és más Java EE API-k, valamint a Spring) teljesen megőrültek az annotációk használatában. Ismételje meg utánam:

Nincs nyelv @Before vagy @After Java valaha visszaélt kommentárok, mint Java

(a @Before / @ After ötlet lennoffé volt, a reddit-en)

a fentieket olvasva erős d ++ j Vu van bennem. Emlékszel a következőkre?

Nincs nyelv előtt vagy után Java valaha visszaélni ellenőrzött kivételek, mint Java

mindannyian mélyen megbánni Java annotations 2020-ig.

a kommentárok egy nagy szemölcs a Java típusú rendszerben. Rendkívül korlátozott indokolt felhasználásuk van, és amit mi, Java vállalati fejlesztők manapság csinálunk, egyáltalán nem az “indokolt”határain belül van. Visszaélünk velük olyan dolgok konfigurálása miatt, amelyekre valóban kódot kellene írnunk.

így futtathatja ugyanazt a lekérdezést a jOOQ – val (vagy bármely más API-val, amely generikus és típusbiztonságot használ az SQL számára):

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

ez a példa egyesíti mind a JPA 2.1 megjegyzéseit, mind a lekérdezéseket. A kivetített “entitásokra” vonatkozó összes metainformáció már szerepel a lekérdezésben, tehát a Result – ban, amelyet a fetch() módszerrel állítanak elő. De ez nem igazán számít, a lényeg itt az, hogy ez a lambda kifejezés …

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

… bármi lehet, amit akarsz! Mint a kifinomultabb példák, amelyeket az előző blogbejegyzésekben bemutattunk:

• nincs több szükség ORMs
• Alakítsa át az SQL adatok diagramok segítségével jOOQ és JavaFX

Mapping lehet meghatározni ad-hoc, menet közben, a funkciók használatával. A függvények az ideális leképezők, mert vesznek egy bemenetet, kimenetet hoznak létre, és teljesen hontalanok. És a legjobb dolog a Java 8 függvényeiben az, hogy a Java fordító fordítja őket, és felhasználhatók a leképezés típusellenőrzésére. Az objektumokhoz funkciókat is hozzárendelhet, amelyek lehetővé teszik a funkciók újrafelhasználását, ha egy adott leképezési algoritmus többször is használható.

valójában maga az SQL SELECT záradék is ilyen függvény. Olyan függvény, amely a bemeneti sorokat / sorokat kimeneti sorokká / sorokká alakítja, és ezt a függvényt menet közben adaptálhatja további kifejezésekkel.

az előző JPA 2.1 natív SQL utasításban és a @SqlResultSetMapping példában semmi sem ellenőrizhető. Képzelje el, hogy megváltoztatja az oszlop nevét:

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

észrevetted a különbséget? A b.titleoszlopot átnevezték book_title – re. Egy SQL karakterláncban. Ami futási időben felrobban! Hogyan lehet emlékezni arra, hogy alkalmazkodnia kell

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

… ahhoz, hogy

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

ezzel szemben, hogyan kell emlékezni, hogy ha átnevezi a column a @FieldResult, akkor is meg kell nézni, ahol ez a "BookAuthorMapping" használják, valamint módosítsa az oszlop nevét azokban a lekérdezésekben.

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

a kommentárok gonoszak

lehet, hogy nem ért egyet a fentiekkel. Lehet, hogy nem tetszik a jOOQ a JPA alternatívájaként, ez teljesen rendben van. De nagyon nehéz nem egyetérteni azzal a ténnyel, hogy:

• Java 5 bevezetett nagyon hasznos kommentárok
• Java EE / Spring erősen visszaélt e kommentárok helyett XML
• most már van egy párhuzamos univerzum típusú rendszer Java
• ez a párhuzamos univerzum típusú rendszer teljesen haszontalan, mert a fordító nem tud önvizsgálatra ez
• Java SE 8 bevezeti a funkcionális programozás és sok típusú következtetés
• Java SE 9-10 fog bevezetni több félelmetes nyelvi funkciók
• most már világossá válik, hogy mi volt konfiguráció (XML vagy kommentárok) kellett volna kódot az első helyen
• JPA 2.1 lett az új EJB 2.0: elavult

mint mondtam. Nehéz nem érteni egyet. Vagy más szavakkal:

a kód sokkal jobban kifejezi az algoritmusokat, mint a konfiguráció

személyesen találkoztam Thorben-nel számos alkalommal konferenciákon. Ez a henceg itt nem azt jelentette, személyesen, Thorben: -) a cikkek a JPA nagyon érdekes. Ha a cikk olvasói JPA-t használnak, kérjük, nézze meg Thorben blogját: http://www.thoughts-on-java.org.

időközben szeretném kinevezni Thorben-t az “év Annotatiomaniac 2015”