last time I brought up JPA, I think the consensus became; too complex to
bother. But I think the need for "conventional persistence"
interoperability is still an issue for us, and I think it should be tackled.

Spring (and others?) are promoting a Repository-pattern for Spring Data
JPA[1] and perhaps this is an abstraction that is reasonable to adapt to.

We could either expose a relatively simple Repository SPI for an
entitystore.repository to use, which only deals with the exact operations
that the UnitOfWork needs, OR we could call it a entitystore.springdatajpa
and interface directly with Spring Data JPA's API.

The former is much more flexible and allows users to create an arbitrary
repository, such as a Rest server, but will require the user a bunch of
more work. The latter will be very specific to Spring Data JPA, but we can
probably handle the entire setup without much user interaction. The
downside is that people is likely to quickly request more features from
Spring Data to be supported, and it may become a mess in the long run.

Of course, we could also do both.

Any insights, ideas and arguments are most welcome.


Niclas Hedhman, Software Developer - New Energy for Java

Reply via email to