JPQL ja SQL lauseet ulos JPA Criteria kyselyistä

Jahas, yksi mielenkiintoinen kysymys mihin on koulutuksissa ja projekteissa törmännyt on, miten JPA Criteria kyselyitä saisi jotenkin paremmin ymmärrettyä/debugattua. Nehän voivat olla aika hirveätä luettavaa ja ymmärrettävää ja vaikeaa hahmottaa miten ne muuttuvat SQL lauseiksi kannassa. Toki voi laittaa show_sql asetuksen päälle mutta muukin näkyvyys auttaisi.

Törmäsin artikkeliin jossa tätä ihmeteltiin. Näyttäisi pähkinänkuoressa siltä että nykyään pitää tehdä joka toteutukselle eri tavalla – no niinpä tietysti! Mutta artikkelin kirjoittaja heitti pallon JPA 2.1 kehittäjille joten tiedä vaikka tähänkin standardoituisi vielä joskus siirrettävä rajapinta esim. Java EE 7 releaseen. Sellaista odotellessa ,tässä on koodia eri toteutuksille:

EclipseLink:

findAllBooks.unwrap(JpaQuery.class).getDatabaseQuery().getJPQLString(); // doesn’t work for CriteriaQuery
findAllBooks.unwrap(JpaQuery.class).getDatabaseQuery().getSQLString();

Hibernate:

findAllBooks.unwrap(org.hibernate.Query.class).getQueryString()

OpenJPA:

findAllBooks.unwrap(org.apache.openjpa.persistence.QueryImpl.class).getQueryString()

Pääideana on siis käyttää CriteriaQueryn (findAllBooks) unwrap-metodia, valitettavasti Query toteutus on erilainen eri toteutuksille, tässä taulukko eroista:

ORM Framework Query implementation How to get the JPQL String How to get the SPQL String
EclipseLink JpaQuery getDatabaseQuery().getJPQLString()* getDatabaseQuery().getSQLString()**
Hibernate Query N/A getQueryString()
OpenJPA QueryImpl getQueryString() N/A

 

Enpä testaillut näitä vielä mutta pistän muistiin vastaisen varalle. Criteria API sopii erityisen hyvin dynaamisiin kyselyihin joiden rakenne elää parametrien perusteella.

Ja tarinan lähde: http://agoncal.wordpress.com/2012/05/24/how-to-get-the-jpqlsql-string-from-a-criteriaquery-in-jpa/

 

Oracle vs Google

No niin, nyt tuli jenkkien suunnalta jonkunmoinen päätös Oracle vs Google oikeudenkäynnille joka koski Java käyttöä Android alustalla ilman lisenssiä.

Valamiehistön pohdinnan (30min) jälkeen päätös oli että Google ei rikkonut Oracle patentteja vastaan. Pohdintaan jäi vielä voiko rajapintoja patentoida, mutta silti mielenkiintoinen voitto. Patenttioikeudenkäynnit ovat aina testejä, joilla linjataan jatko. Tässä tapauksessa Googlen  häviö olisi pistänyt vaakalaudalle sen pysyykö Android laitteissa ohjelmointikielenä Java. Googlen voitto taas antaa kummasta lisää buustia mobiililaitteisiin, etenkin kun Google-Motorola kauppa meni läpi ja kentällä liikkuu huhuja tulevista Google-laitteista softan ja raudan yhdistyessä.

Mielenkiintoisinta tässä että mielestäni silti oikeudenkäynnissä Oraclella oli pointtinsa – Java oli ja on käytössä kielenä ja kirjastoina laitteissa ilman lisensointia, Google olisi voinut valita kaupalliseen käyttöön lisensoida alustan tai kehittää täysin erillisen ja uuden kielen ja alustan, mutta sensijaan ratsastaa Javan maineella ja tunnettuvuudella, ja muunteli siitä itselleen sopivan. Toisaalta ilman Android imua Java kieli voisi olla huomattavasti synkeämmässä jamassa kuin mitä se on – Android on piristysruiske sekä mobiililaitteille että Java-ekosysteemille kokonaisuutena.

Kiintoisa huomio: Jos rajapinnat voi patentoida yhdysvalloissa, mutta ei Euroopassa, arvatkaapa minne kaikki startup-yritykset siirtyvät..

Joka tapauksessa, maailma tarvitsee selkeästi enemmän koodaavia lakimiehiä ja tuomareita tulevaisuudessa. 😉

Sudenkuoppia Try-With-Resources kanssa

Mielenkiintoinen artikkeli Java 7 try-with-resources sudenkuopista:

http://java.dzone.com/articles/common-try-resources-idiom?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+%28Javalobby+%2F+Java+Zone%29

Sinänsä vähän haettuja että kuvatut ongelmat ovat harvinaisia. Jos tiedosto on jo saatu auki, puskurivirran epäonnistuminen voisi johtua lähinnä muistin loppumisesta, ja jos niin käy, sulkematon resurssi on yksi pienimmistä ongelmista. Mutta silti, hyvää kuranttia tavaraa, ja auttaa ymmärtämään paremmin miten try-with-resources toimii.

 

Androidia ja koodaava tuomari

No niin, nyt on Android Ohjelmointi II pidetty, ja käytiin läpi aikalailla hauskoja ja hyödyllisiä Android rajapintoja. Kurssilaiset kävelivät ympäri luokkaa paikannus-rajapintoja testaillessaan ja testailu jatkoi kurssin jälkeen. OpenGL:llä väännettiin kosketukseen reagoivaa taustaväriä. Kolme päivää on aika piukka aikataulu käydä ohjelmointikurssia läpi, mutta siinä ehtii saada ensi askelen edistyneisiin rajapintoihin ja lisää varmuutta perusvääntöön.

 

Taisin jo aiemminkin bloggailla siitä, miten Google-Oracle Android-oikeudenkäynnissä tuomari Alsup käväisi java-ohjelmoinnin perusteet kurssilla ymmärtääkseen mitä oikeussalissa puhutaan. Nyt homma on mennyt eteenpäin: Viimeisimmän tiedon mukaan tuomari Alsup on koodaillut pikkuhiljaa Javaa vapaa-ajallaankin, ja nauraa nyt väitteille patentoidusta koodista. Kohteena oli 9 riviä rangeCheck() funktion koodia, mitä kiista nykyisellään koskee, ja tuomarin mukaan hän on koodaillut vastaavat pätkät lukuisia kertoja ja koodi on suorastaan triviaalia. Way to go tuomari!

En sinällään ota kantaa tuohon oikeudenkäyntiin muuten, se on oivallinen soppa kaikin tavoin, mutta miten ikinä siinä käykin, vaikutukset ovat pitkäkestoiset alalla. Mielestäni kuitenkin hienoa että tuomari vaivautuu perehtymään kohteena olevaan asiaan henkilökohtaisesti, ja olisiko myös aika alkaa opettamaan kouluissa ihan jokaiselle Javaa kolmantena kotimaisena kielenä? 😉

Tästäpä voi lukea lisää esim. http://developers.slashdot.org/story/12/05/16/1612228/judge-to-oracle-a-high-schooler-could-write-rangecheck?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot+%28Slashdot%29