Upgrade "pulito" di un database "sporco" con hibernate

Interessante articolo, almeno dal punto di vista strettamente pratico, sul come aggiornare la struttura di un database legacy, o comunque esistente e non modificabile, usando Hibernate e qualche altra strategia da db admin.

Lo scenario di partenza è quello in cui si opera, usualmente, sia nell'ambito dei system integrator che durante l'evoluzione naturale di un software.

Quindi, supponete di avere un database, non normalizzato,
ricco delle solite porcate generate da evoluzioni incontrollate "perchè le ha chieste il cliente".

Inoltre, supponete che al database accedano anche altre applicazioni che non potete modificare.

Infine, supponete di voler costruire una nuova applicazione bella bellina, tutta perfettina che vuole uno schema normalizzato e che tanto desidera usare Hibernate per l'accesso al database.

Bene questo articolo è esattamente quello che fa per voi.

L'approccio usato è un misto di viste ausiliare, stored procedure e mappature Hibernate sulle stored procedure.

Quello che otterrete alla fine è ben esplicitato da questo disegnino.



Volendo si potrebbe anche arguire che la logica di normalizzazione si poteva spostare in uno strato DAO, magari gestito da EJB3, ma comunque l'esempio è molto carino e pragmatico.

Consigliato per tutti quelli che hanno a che fare quotidianamente con "il vecchio database" o con "quello schifo di database del gestionale xyz".

Due notiziette per GWT e Hibernate

Oggi son di corsa e vi lascio solo due notiziole mignon.

Hibernate

E' stata rilasciata una nuova versione (minor) di Hibernate, la 3.2.3ga
Le novità sono:

• due nuovi generatori
  
• la certificazione per il database Teradata (non l'avevo mai sentito prima...)
• i soliti fix

Chiaramente se usate 3.2.x in qualche progetto, vi basta sostituire il jar con quest'ultimo per fixare i bug.

GWT

Dan Morrill, dello staff del Google Web Toolkit, ha scritto un interessante articolo sulla sicurezza per applicazioni ajax in GWT.
Sinceramente non ho ancora trovato il tempo di leggerlo completamente, ritornerò sull'argomento uno dei prossimi giorni.

Bye!

Le proposte del papà di Hibernate per Java EE 6

Gavin King, per chi non lo conoscesse, è il papà di Hibernate, l'arcinoto framework di persistenza. Gavin, iniziò a scrivere hibernate per averla vinta con il suo capoufficio (come scrisse tempo fa in un post che non riesco a recuperare). Dopodichè Hibernate crebbe fino a diventare il più popolare e performante ORM java. Venne quindi acquisito da JBoss, di cui Gavin è ora dipendente. Allo stesso tempo l'autore entrò a far parte del gruppo che scrisse la JSR per Java EE 5... i famosi EJB3. Di fatto questi non furono altro che un set di annotation e specifiche cucite attorno ad hibernate.

Oggi Gavin ha pubblicato la sua (parziale) wish list di specifiche per la prossima versione di Java EE. La 6. Alcune, di fatto sono già implementate in JBoss Seam, per cui se la storia insegna, le vedremo nuovamente cucite in EJB4.

Ci aspettiamo a breve nuovi post sulla questione. Per adesso vi riassumo le proposte per i nuovi Session Bean, tutte specificabili via annotation:

Concorrenza

tre tipi di concorrenza forniti dal container

• session bean senza concorrenza (come adesso)
• session bean con concorrenza gestita dal container: la serializzazione delle chiamate è garantità dall'application server (esempio: Session Bean singleton)
  
• session bean con concorrenza gestita dal container: i synchronized sono a vostro carico

Metodi asincroni

Possibilità di marcare un metodo asincrono (con @Asynchronous), cioè in modo che la sua chiamata non sia bloccante per il chiamante e sia cura dell'application server aprire su un altro thread l'esecuzione del metodo. Direte: si può già fare con il sistema di messagging. Sì, ma quella suggerita da Gavin è un'infrastruttura più leggera di JMS.

Endpoit per webservice WS-blablabla

Possibilità di marcare uno stafeful bean come endpoint di un web-service con stato specificato da molte delle WS-qualcosa. Ad esempio WS-Transaction.
Qui il nostro caro, ha ancora le idee un po' confuse.

Interfaccia business opzionale

La rindondanza della @Local è roba nota, e non ve la ripeto. Gavin "pretende" di togliere il problema. Inoltre fa pubbliche scuse sull'implementazione attuale in EJB3... effettivamente è uno dei pochi che può farlo ;)

Loggers e JMS queues iniettabili

Possibilità di iniettare il classico logger o una coda di messaggi in modo semplice. In Seam già si fa.

Meta-annotation

Questa è bellissima. In un mondo dove ci saranno più annotation che codice, Gavin propone di introdurre una sorta annotation contenitore che esprima tutte le altre in un sol colpo. Direi che questa ci vorrà per forza.


Per ora questo è tutto. Vi terrò aggiornati sul proseguimento delle proposte.

Hibernate incontra Shard e va orizzontale

Il framework di Hibernate si arricchisce ancora con una nuova utilissima estensione: Hibernate Shard

Detta in breve, Hibernate Shard consente di estendere in modo completamente trasparente il layer di Hibernate ad un contesto con più database.
Diciamolo ancora più terra terra. Supponete di avere i dati sparsi in più database (per motivi legali, di prestazioni, o per riesumazioni di applicazioni datate) e di voler persistere i vostri oggetti per alcuni campi su un database e per altri su un'altro database. Bene, Hibernate Shard fa esattamente questo: senza modificare il vostro modello ad oggetti vi basterà ridefinire in quali database persistere i singoli campi e Shard organizzerà per voi transazioni distribuite nella solita chiara e trasparente veste di Hibernate.

Ovviamente il tutto funziona anche a rovescio, qualora decideste di eseguire delle select distribuite.

E, un po' meno ovviamente, anzi quasi miracolosamente, il tutto funziona anche qualora voleste avere più repliche dello stesso db, e per ragioni di performance voleste lanciare select computazionalmente pesanti, ad esempio con politica round robin sulle singole repliche.

L'estensione è stata realizzata dai soliti buontemponi di Google nel loro arcinoto 20% di tempo libero.