Criteri/Criteri stile JPA Query di fabbri dalla sessione di ibernazione

Question

Ho un'applicazione che utilizza Hibernate 4.xe attualmente sta utilizzando le API native di Hibernate (ovvero ho un SessionFactory e Session s). Ho appena noticed che i criteri di API esistente è deprecato in favore di API (superiore) Criteri dell'APP:

Hibernate offre un'eredità org.hibernate.Criteria API più vecchio che dovrebbe essere considerato deprecato. Nessuno sviluppo di funzionalità si rivolgerà a tali API. Alla fine, le caratteristiche dei criteri specifici di Hibernate verranno convertite come estensioni all'APP javax.persistence.criteria.CriteriaQuery.

Io non voglio avere per convertire la mia applicazione verso utilizzando EntityManager direttamente (anche se è facile ottenere un Hibernate Session da lì) perché abbiamo una grande quantità di costume Hibernate logica di configurazione che dovrà essere rimpiazzato. Ciononostante, voglio assolutamente iniziare a utilizzare le API dei Criteri JPA, poiché le vecchie API sono deprecate (e presumibilmente scompariranno in qualche punto casuale in futuro, se le versioni successive di Hibernate sono indicative) e forniscono anche una sicurezza di tipo molto migliore.

Come posso utilizzare la nuova API CriteriaQuery/CriteriaBuilder, se sto utilizzando SessionFactory/Session?

Answer 1

Abbiamo lo stesso dilemma nel nostro progetto. Il progetto è davvero complicato: il 90% delle entità viene generato dinamicamente; c'è un livello API implementato sopra l'API dei criteri di Hibernate, un DAO pesante e un livello di servizio, che è molto usato; la nostra versione di ibernazione è patchata molte volte per supportare funzionalità specifiche (come il tipo START WITH/CONNECT BY, in oracolo e così via); postgresql e oracle vengono utilizzati entrambi, in alternativa ecc.

La nuova API JPA sarebbe molto utile per noi. Abbiamo bisogno dell'abilità di utilizzare le funzioni a livello di Criteria API (non HQL) (come NVL/coalesce per alcuni tipi di prestazioni, substring, trim e così via). Inoltre abbiamo bisogno di Hibernate Envers che è disponibile solo per l'implementazione JPA "EntityManager".

Infelicemente, in base ai risultati della nostra ricerca, non è possibile utilizzare l'API dei criteri JPA da Hibernate nativo. Anche Envers non può essere usato. Il progetto Hibernate è in continua evoluzione e sta acquisendo nuove funzionalità. La migrazione alle nuove versioni di ibernazione è un compito molto complicato per noi. E siamo molto preoccupati dall'incapacità di utilizzare molte nuove funzionalità delle nuove versioni dopo la migrazione e di crescere con questa struttura di base.

Pertanto consideriamo due modi possibili per noi: utilizzare SQLCriterion con la propria implementazione di Expression s (i nomi delle colonne si risolvono con CriteriaQuery e tradurre to SQL) o la migrazione a "EntityManager"/CriteriaBuilder. La seconda via sembra inevitabile. Ma la migrazione all'implementazione di JPA porta molti problemi nascosti che rovinano il nostro progetto.

Se sceglieremo la migrazione e sarà utile, lascerò qui quali problemi avremo a che fare in questa attività.