Tag:

skønhed ligger i øjet af beskueren. Så gør “lethed”:

Thorben skriver meget gode og nyttige artikler om JPA, og han har for nylig startet en fremragende serie om JPA 2.1 ‘ s nye funktioner. Blandt hvilke: resultat sæt kortlægning. Du kan kende resultat sæt kortlægning fra hjemmesider som CTMMC, eller annotatiomania.com. vi kan opsummere denne kortlægningsprocedure som følger:

a) Definer kortlægningen

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

ovenstående kortlægning er ret ligetil. Det specificerer, hvordan databasekolonner skal knyttes til enhedsfelter og til enheder som helhed. Derefter giver du denne kortlægning et navn ("BookAuthorMapping"), som du derefter kan genbruge på tværs af din ansøgning, f.eks.

jeg kan specifikt lide det faktum, at Thorben derefter skriver:

hvis du ikke kan lide at tilføje en så stor blok af kommentarer til din enhed, kan du også definere kortlægningen i en

… så, vi er tilbage til at erstatte enorme blokke af anmærkninger med enorme blokke af HML-en teknik, som mange af os ønskede at undgå at bruge anmærkninger… :- )

b) Anvend kortlægningen

når kortlægningen er statisk defineret på en Java-type, kan du derefter hente disse enheder ved at anvende ovenstående 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;});

bemærk, hvordan du stadig skal huske Book og Author typerne og cast eksplicit, da ingen verificerbare typeoplysninger virkelig er knyttet til noget.

definitionen af “kompleks”

nu hævder artiklen, at dette er “kompleks” kortlægning, og uden tvivl er jeg enig. Denne meget enkle forespørgsel med kun en simpel sammenføjning udløser allerede et sådant annotations rod, hvis du virkelig vil kortlægge dine enheder via JPA. Du ønsker ikke at se Thorbens kortlægningsanmærkninger, når forespørgslerne bliver lidt mere komplekse. Og husk, @SqlResultSetMapping handler om kortlægning (native! Vi er ikke længere i objekt-graph-persistens land, vi er i kvm land, hvor bulk hentning, denormalisering, aggregering og andre “fancy” kvm ting er konge.

problemet er her:

Java 5 introducerede kommentarer. Kommentarer var oprindeligt beregnet til at blive brugt som “kunstige modifikatorer”, dvs. ting som static, final, protected (interessant nok kender Ceylon kun kommentarer, Ingen modifikatorer). Det giver mening. Java-sprogdesignere kunne introducere nye modifikatorer / ” nøgleord “uden at bryde eksisterende kode – fordi” rigtige ” nøgleord er reserverede ord, som er svære at introducere på et sprog. Husk enum?

så gode brugssager til kommentarer (og der er kun få) er:

• @Override
• @Deprecated (selvom, en kommentarattribut ville have været fancy)
• @FunctionalInterface

JPA (og andre Java EE API ‘ er, samt foråret) er gået helt skøre på deres brug af anmærkninger. Gentag efter mig:

Ingen Sprog @Before eller @After Java nogensinde misbrugt anmærkninger Så meget som Java

( @før / @efter ideen var lennoffs, på reddit)

der er en stærk d-Kurt i mig, når jeg læser ovenstående. Kan du huske følgende?

intet sprog før eller efter Java nogensinde misbrugt kontrollerede undtagelser så meget som Java

vi vil alle dybt fortryde Java-kommentarer inden 2020.

anmærkninger er en stor vorte i Java type system. De har en ekstremt begrænset berettiget brug, og hvad vi Java Enterprise-udviklere gør i disse dage er absolut ikke inden for rammerne af “berettiget”. Vi misbruger dem til konfiguration for ting, som vi virkelig burde skrive kode til.

Sådan kører du den samme forespørgsel med Jook (eller enhver anden API, der udnytter generiske og typesikkerhed til):

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

dette eksempel kombinerer både JPA 2.1 ‘ s anmærkninger og forespørgsler. Alle meta-oplysninger om projicerede “enheder” er allerede indeholdt i forespørgslen og dermed i Result, der er produceret af fetch() – metoden. Men det betyder ikke rigtig noget, pointen her er, at dette lambda-udtryk …

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

… det kan være hvad du vil! Ligesom de mere sofistikerede eksempler, vi har vist i tidligere blogindlæg:

• ikke mere behov for ORMs
• Omdan dine data til diagrammer ved hjælp af Jook og Javaf

kortlægning kan defineres ad hoc, i farten, ved hjælp af funktioner. Funktioner er de ideelle kortlæggere, fordi de tager et input, producerer et output og er helt statsløse. Og det bedste ved funktioner i Java 8 er, at de er udarbejdet af Java compiler og kan bruges til at skrive-kontrollere din kortlægning. Og du kan tildele funktioner til objekter, som giver dig mulighed for at genbruge funktionerne, når en given kortlægningsalgoritme kan bruges flere gange.

faktisk er klausulen i sig selv en sådan funktion. En funktion, der omdanner input tupler / rækker i output tupler / rækker, og du kan tilpasse denne funktion på flue ved hjælp af yderligere udtryk.

der er absolut ingen måde at skrive-kontrollere noget i den tidligere JPA 2.1 native KVL-erklæring og @SqlResultSetMapping eksempel. Forestil dig at ændre et kolonnenavn:

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

har du bemærket forskellen? Kolonnen b.title blev omdøbt til book_title. I en streng. Hvilket blæser op på køretid! Sådan husker du, at du også skal tilpasse dig

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

… at være

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

omvendt, hvordan man husker, at når du omdøber column i din @FieldResult, skal du også tjekke, hvor denne "BookAuthorMapping" bruges, og også ændre kolonnenavne i disse forespørgsler.

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

anmærkninger er onde

du er måske eller måske ikke enig i nogle af ovenstående. Du kan måske ikke lide JPA som et alternativ til JPA, det er helt fint. Men det er svært at være uenig i, at:

• Java 5 introducerede meget nyttige kommentarer
• Java EE / Spring misbrugte stærkt disse kommentarer til at erstatte
• vi har nu et parallelt univers type system i Java
• dette parallelle univers type system er helt ubrugeligt, fordi kompilatoren ikke kan introspect det
• Java SE 8 introducerer funktionel programmering og masser af type indledning
• Java SE 9-10 vil introducere flere fantastiske sprogfunktioner
• det bliver nu klart, at hvad der var konfiguration (HML eller kommentarer) burde have været kode i første omgang
• JPA 2.1 er blevet den nye EJB 2.0: forældet

som jeg sagde. Svært at være uenig. Eller med andre ord:

kode er meget bedre til at udtrykke algoritmer end konfiguration

jeg har mødt Thorben personligt ved en række lejligheder på konferencer. Denne rant her var ikke ment personligt, Thorben: -) dine artikler om JPA er meget interessante. Hvis du læsere af denne artikel bruger JPA, så tjek Thorbens blog: http://www.thoughts-on-java.org.

i mellemtiden vil jeg meget gerne nominere Thorben til den respekterede titel “Årets Annotatiomaniac 2015”