2016-06-23 75 views
5

Recentemente ho avuto il piacere di poter eseguire il dump della versione della dipendenza di Hibernate (tra le altre) in una base di codice legacy di medie dimensioni (dalla 3.x alla 5.2). Il codice stesso ha in parte più di 10 anni ma è ancora nell'uso quotidiano.Qual è il percorso di aggiornamento previsto per le applicazioni legacy di Hibernate?

Quindi, anche dopo aver aumentato la versione e portato tutte le chiamate API lontano da aree ormai deprecate o mancanti alle loro controparti all'avanguardia (scoprire come fare uno SchemaExport è stata un'esperienza particolarmente divertente) Non vedo ancora questo come una migrazione completa.

Mi chiedo quale sia il percorso di aggiornamento previsto per gli utenti legacy, poiché spesso i sistemi aziendali dureranno da 10 a 15 anni e ancora a volte è necessario passare a una versione di dipendenza più recente per ottenere le correzioni o le correzioni necessarie.

I seguenti punti sono alquanto ancora aperti:

  • Non c'è modo chiaro o automatico migrare informazioni di mappatura .hbm.xml per annotazioni APP. So che una migrazione manuale sarà molto soggetta a errori e non tutti i concetti hanno parti contrapposte chiare o ovvie.

  • Ora riceviamo molti avvisi di deprecazione (org.hibernate.orm.deprecation) sul nostro utilizzo della vecchia API Criteri ma non esiste un chiaro percorso di aggiornamento. Non si può semplicemente riscrivere l'intero codice di accesso db di un'applicazione a un'API completamente diversa e più verbosa che si comporterà sicuramente in alcuni casi limite.

  • Sembra che utilizziamo un sacco di query native e istanze di org.hibernate.transform.ResultTransformer ma il org.hibernate.query.Query#setResultTransformer() sembra essere deprecato senza alcuna indicazione su come aggirare questo problema.

In generale, la documentazione relativa alla deprecazione e ai percorsi di aggiornamento previsti sul lato di Hibernate sono scarsi. Capisco che si tratta di un progetto Open Source e che non vogliono mantenere per sempre le vecchie API ma comunque mi sento un po 'perso e non credo che questa sia l'unica applicazione legacy Java ancora in uso oggi.

+0

La maggior parte delle vostre preoccupazioni sono coperte dall'esistenza di test di integrazione. Dato che lavori su sistemi legacy, suppongo che tu non ne abbia. Questo sarebbe il tuo problema principale, non il fatto che Hibernate si sia evoluto nel tempo. Ho fatto un upgrade simile, ma ho anche aggiornato il server (JBoss 5.1 a Wildfly 9) e JSF (1.2 + JBoss Seam a JSF 2.2 + Primefaces) - è stata un'esperienza strabiliante che ha richiesto 6 mesi di riprogettazione del codice. Questo è solo il modo in cui è con i sistemi legacy - e perché molti scelgono di non aggiornare. – Gimby

+0

Quali sono i modelli e le tecnologie utilizzati nell'applicazione? Voglio dire che l'applicazione utilizza MVC, per il livello di servizio si utilizza Spring, EJB o qualcosa del genere. –

+0

Posso suggerire di eseguire l'aggiornamento a 5.1 e non ancora a 5.2? La 5.2 riguarda molto "spianare la strada" verso Hibernate 6 e deprecating alcune cose che sappiamo saranno rimosse, ma in effetti non tutto è ancora chiaro. Anche alcune modifiche sono andate un po 'troppo lontano e stiamo ripristinando un po' in 5.2.1, ovvero https://hibernate.atlassian.net/browse/HHH-10877 – Sanne

risposta

1

Capisco cosa intendi. In effetti, recentemente ho visto ogni sorta di domande sul nostro forum riguardanti la migrazione da 3.x a 4.xe 5.x.

  1. Penso che dovremmo avere una pagina di destinazione della migrazione come pagina iniziale per ogni migrazione. In questo modo, gli utenti dovranno andare su una singola pagina e trovare tutto ciò di cui hanno bisogno.
  2. Non abbiamo uno strumento automatico da HBM a annotazioni. Tuttavia, c'è un'alternativa. È possibile eseguire HBM -> database e quindi utilizzare lo strumento Reverse Engineer per generare annotazioni dallo schema del database.
  3. I criteri legacy sono deprecati poiché non possiamo più permetterci di mantenere due API Criteri. Inoltre, i criteri JPA sono più avanzati (ha query di tipo safe e Metamodel). Sfortunatamente, non esiste alcuna migrazione automatica dalla legacy all'API dei criteri. Ma poi, anche se disponi di centinaia di chiamate al metodo, puoi facilmente migrarle automaticamente (regex/perl/vi) o manualmente. Non ci vorrà molto per farlo.
  4. Il ResultTransformer sarà sostituito con un nuovo meccanismo che può sfruttare meglio Lambda. Per questo motivo, la nuova interfaccia o le interfacce dovranno essere interfacce funzionali.
+0

Grazie per aver trovato il tempo di rispondere alla mia raccolta di non molto domande specifiche. :) – aeisele