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 ilorg.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.
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
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. –
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