Can JPA/Hibernate be combined with other persistence framework like jOOQ

Question

We have domain that where 90% of the classes are very straightforward and can be easily mapped 1:1 in the DB. I am very happy how Hibernate combined with spring-data-jpa removes tons of chores for these classes.

The rest of the domain however is challenging and for number of reasons I don't want to directly map it to DB tables.

I did experiment to introduce intermediate beans that are managed by Hibernate and map from these beans to my domain and this worked well when all relations are from the challenging to the easy part. This approach fails when I have "easy" class managed by Hibernate that references "challenging" class that is mapped in custom Java code and not directly hibernate managed.

This is when I realized I cannot find no way to customize Hibernate and plug in some sort of ObjectFactory that would allow me to do such transformations on the fly.

--edit--

What is my question: What is the easiest way to have DDD-style domain layer that has zero DB concerns in the entities, while using JPA? In DDD all DB concerns are handled by the Repository which typically collaborates with DAOs.

Zero DB concerns in the entities means there are no JPA annotations or mapping configurations in the Domain classes. One way to do it is to have JPA (or other persistence technology) manage TOs that are mapped to the Domain Entities. If I take this route however I have to have all of my entities, even the simplest one (think Address) go via the mapping layer.

I would like to use something "lazy" like JPA for the trivial entities and be able to mix them with the other entities that are "manually" managed. Currently I do not know clever solution that allows me to have link from JPA managed entity to non-JPA managed entity. I can always retrieve the JPA entity and then retrieve the non-JPA entity with second call but would like to avoid this if possible.

Answer 1

You can combine JPA and jOOQ. JPA/Hibernate are great for writing data:

• all entity columns are included in the INSERT/UPDATE, so you don't have to change the save routines when adding new columns
• extensive support for both implicit/explicit optimistic/pessimistic locking
• support for optimized identifier generators (pooled-lo optimizer)
• transactional write-behind cache to reduce lock contention (even in MVCC DBs)
• JDBC fetching is just one configuration away

SQL and jOOQ are great for reading data and especially when you want to go beyond the SQL-92 JPA Dialect abstraction. With native queries (and type-safe jOOQ), you can take advantage of every feature your database has to offer:

• Window functions
• PIVOT
• Derived tables
• Common Table Expressions and Recursive queries
• MERGE
• Bulk INSERTS/UPDATES

In the end, you will most likely need both JPA and native queries, so jOOQ is a great choice for getting the most of your current database while giving you ca compile-time safety guarantees.