This is a tough, but interesting question ...... I have seen a few other attempts at bridging the NoSql with the JPA world - you could consider taking a look at DataNucleus or Hibernate OGM.
Both seem to generate native queries based on the JPA API (similar to the Zest QueryBuilders) - and then attempt to integrate all changes with the global (XA) transaction of the Application Server (constrained be the presence/absence of XA support in the stores). I am not quite convinced it would be the way to do this - the fit between the Zest entities and the JPA API is not quite obvious to me - but a similar strategy *should* be possible. But is it really what is asked for? - would it be better to allow more seamless integration where parts of an application is persisted in a traditional relational database (using JPA), and other parts are "DDD/Zest" entities? That could present a nice migration path, I think. And the integration would be, not so much on the query/persistence part, but more in the UnitOfWork/transaction part. A few ideas: (1) If the persistence engines in the entitystores are XA capable (such as for JDBC/NEO4J entitystores) it should not be too difficult. The basic idea would be to inject a DataSource provided by the appserver into the EntityStore and let the EntityStore avoid committing - leaning on commit of the global XA transaction - and postpone notifying indexers until the global transaction is committed (we should be able to listen to "commit events"). (2) Abother possible strategy could be to let the UnitOfWork be a resource managed by the appservers transaction manager - A lot more complex! But maybe we could be able to use a "last resource gambit" - so the UOW will need to be a resource managed by the TransactionManager, but at least it should not be necessary to be XA compliant. (3) Another idea could be to separate the UOW completion from the "flush" to the EntityStore(s). Right now the "definition" of UOW#complete is flushing changes to the EntityStore(s) - with the (eventual?) sideeffect of notifying indexers. What if this was changed, so that the "definition" of UOW#complete is persisting some record to a UnitOfWorkLog - with the (eventual) sideeffect of flushing changes to EntityStore(s) - with the (eventual) sideeffect of notifying indexers. (actually this is not too far from eventsourcing - so maybe the UnitOfWorkLog is simply an "EventStore"?). The point is that the unitOfWorkLog could have a fixed schema, making it suitable for an (XA-compliant) relational database. A call flow could be: - interceptor1 starts global transaction - interceptor2 start UOW - some changes are made to JPA entities - some changes are made to Zest entities - interceptor2 completes UOW (updates UOWLog record in a relational database) - interceptor1 commits global transaction - we listen for commit events and calculates/flushes changes to EntityStores based on the UOWLog (this begin to look more and more like an eventstore) - with the sideeffect of notifying indexers.... Not simple, but maybe not too hopeless. Note that this could potentially be useful in a Zest-only app with a single UOW leading to changes to multiple EntityStores. WDYT? /Kent Den 31-07-2016 kl. 01:42 skrev Niclas Hedhman: > I just came across something that has been discussed several times in the > past. It is a anser on [1] > > <quote> > When I read through the Qi4j in 2 minutes, 10 minutes etc. tutorials (the > last one is incomplete), the one obvious question that came to mind was how > do I integrate this with JPA/Hibernate managed entities? I would like to > see a solution that seamlessly integrates with JPA. No JPA implies no Qi4j > adoption in my opinion. I'd love to see an article by the author(s) that > shows integration with JPA and Spring, two things that have deep > penetration in the Java Enterprise world. If the integration is > straightforward, rapid adoption will follow. > </quote> > > As I said, this has surfaced several times in the past, and each time it > has been discarded as "impossible" due to our models are significantly > different from JPA in general and Hibernate in particular. > > Now, since we are breaking compatibility in a major way, the question that > must be asked is; > > Is there anything we can do to make this a possibility? > > Because, even though Hibernate has its serious issues, I think the post > highlights the gist of the problem; Spring and Hibernate is popular. We > should consider that fact seriously. > > > [1] > http://stackoverflow.com/questions/2196612/anybody-using-qi4j/9442920#9442920 > > Cheers
