| +1 for not using both APIs.
I'd be tempted to use JPA as a main API, but we have to check what it means regarding HQL and Criteria (in particular).
Here're the major changes that I see so far in the JSR-352 integration:
| Hibernate API |
Java Persistence API |
| org.hibernate.Criteria |
javax.persistence.criteria.CriteriaBuilder |
| org.hibernate.Criterion |
javax.persistence.criteria.Predecate |
| org.hibernate.criterion.Order |
javax.persistence.criteria.Order |
| org.hibernate.Session |
javax.persistence.EntityManager |
| org.hibernate.StatelessSession |
javax.persistence.EntityManager (1) |
| org.hibernate.SessionFactory |
javax.persistence.EntityManagerFactory |
| org.hibernate.query.Query |
javax.persistence.Query |
(1) However, I'm not sure about this one. Our current architecture uses stateless session to handle the ID fetching and entity reading. It seems that there's no equivalent of stateless session in JPA, so the L1 cache cannot be disabled, which might be a big problem in term of performance. Other problems:
- JPA has more type check, which leads to lot of changes in the criteria, query building. Here's some example of the types:
- X stands for the represented entity type
- T stands for the represented attribute
- Y stands for the represented expression
- Scrollable result does not have equivalent in JPA
- Multi-tenancy: Not sure how to handle it in JPA
- Use FullTextEntityManager instead of FullTextSession in the test.
|
