Migrazione su App Engine

Dopo le verifiche preliminari sulla comprensione dell’effettivo funziona-mento di JPA, passiamo alla parte qualificante di questo test: la stima

4pgAdmin è una semplice GUI per l’amministrazione di un database PostgreSQL: rap-presenta una utile interfaccia grafica per varie operazioni di gestione o interrogazione, come la modifica allo schema SQL, la creazione di query e la visualizzazione del contenuto delle tabelle.

Figura 3.2: Dati inseriti datest-crud-single su provider Hibernate

del grado di difficoltà nella migrazione di un progetto preesistente verso l’architettura App Engine.

Il primo passo è la creazione di una directorywar all’interno del pro-getto: possiamo ora includere le librerie relative ad App Engine, per questo entriamo nel pannello delleProperties relative al nostro test-crud-single, e andiamo modificare la parte relativa al sotto-menuGoogle.

Entriamo nella voceApp Engine, dove abiliteremo il check-box relativo aUse Google App Engine e setteremo i parametri Application ID e Version coerentemente con l’application id che abbiamo ottenuto nel nostro profilo web.

Nella successiva voceWeb Application verifichiamo che il check-box This project has a WAR directory sia abilitato, e che il path della directory corri-sponda alla directory appena creata.

Osserviamo che alla chiusura del pannello la directory war viene popo-lata con i file JAR della libreria App Engine, e che Eclipse segnala due errori all’interno del progetto: la mancanza dei fileappengine-web.xml e web.xml. Eclipse prevede unaQuick fix che genera automaticamente un template funzionante dei due file, possiamo quindi sfruttare questo utile strumento andando subito a modificare i due sorgenti creati come da appendice A.8 e A.9.

A questo punto il progetto è pronto per utilizzare App Engine, ma per l’accesso sfrutta ancora uno dei due ORM appena testati: se però proviamo a eseguirlo, si verifica subito il primo inconveniente: l’esecuzione fallisce in quanto si genera un’eccezione, nella quale riconosciamo il messaggio ERROR: column jdodetachedstate of relation progettis does not exist.

Ad un primo approccio, sembra che l’introduzione di App Engine ab-bia modificato la definizione dell’entità Progetto, aggiungendo un attributo jdodetachedstate che disturba i nostri ORM, in quanto non sono in grado di applicare la corretta mappatura delle colonne nella relazione sul database. Se verifichiamo il codice sorgente dell’entità non notiamo nessuna modifi-ca, è quindi lecito aspettarsi che tale inconveniente sia dovuto a un qualche tipo di postprocessing che è stato introdotto in fase di compilazione.

Come abbiamo visto in precedenza l’accesso alla persistenza nel Data-store viene gestito attraverso il providerDataNucleus: tale provider si pone come un layer intermedio che traduce la sintassi di persistenza, JPA o JDO, nelle routine di accesso alleBig Table. Per far questo, inserisce appunto

3.1 Persistenza di una singola entità 39 una fase di postprocessing, tramite uno strumento denominato DataNu-cleus Enhancer, che crea una serie di metadati necessari alla traduzione in run-time.

All’interno di questa procedura, viene eseguito anche il JDO Enhan-cement [21] che, operando appunto a livello di bytecode, implementa le interfacce PersistenceCapable e opzionalmente Detachable: è proprio que-st’ultima interfaccia a introdurre l’attributo Object[] jdoDetachedState che disturba gli ORM finora testati.

Per risolvere questo problema vi sono tre strade percorribili:

Abilitare o disabilitare l’Enhancer in base al target di esecuzione del pro-getto: l’Enhancer disabilitato consente l’utilizzo dei primi due ORM testati, ma genera una eccezione se si tenta di utilizzare App En-gine correlata con la mancanza dei metadati, il comportamento è speculare abilitando il post-processing.

Modificare la relazione PostgreSQL aggiungendo allo schema una nuova colonna di tipobytea, denominata appunto jdodetachedstate. Questo evita la generazione dell’eccezione, anche se inserisce dati non stret-tamente necessari nel database: nei successivi test si adotterà questa soluzione. Si noti come la ri-applicazione dello strumento di Eclip-seJPA Tools > Generate Tables from Entities. . . accoppiata all’abilita-zione delDataNucleus Enhancer inserisce automaticamente la nuova colonna nello schema delle tabelle generate.

Modificare l’entità Progetto aggiungendo le due righe @Transient

public Object[] jdoDetachedState;

in modo da renderetransient, ossia non soggetto a persistenza, il cam-pojdoDetachedState: occorre però verificare se tale modifica va ad in-taccare la logica di gestione delle entità in DataNucleus. Si riserva a una successiva analisi la praticabilità di tale opzione.

Dopo queste modifiche, il progetto è abilitato all’utilizzo di App Engine e non presenta malfunzionamenti con gli ORM precedentemente testati.

A questo punto è possibile completare il test, aggiungendo una ulterio-repersistence-unit in persistence.xml (vedi appendice A.7), popolata con i parametri di accesso al Datastore, e definire una semplice servlet (vedi ap-pendice A.5), in modo da reindirizzare i messaggi della classe di test dallo standard output allo stream di uscita visualizzabile nel browser.

In definitiva è possibile testare il funzionamento delle scritture sul Da-tastore sia attraverso l’esecuzione locale tramite il plugin App Engine per Eclipse, sia sul cloud effettuando il deployment nel dominio appspot.

Figura 3.3: Messaggi di output ditest-crud-single su provider App Engine

Il risultato dell’esecuzione sul cloud non differisce dalle varianti su database relazionale.

Verifichiamo l’effettivo funzionamento dei salvataggi su persistenza at-traverso ilDatastore viewer di App Engine.

Figura 3.4: Dati inseriti datest-crud-single su provider App Engine