On Thu 2015-05-07 17:51, Gunnar Morling wrote:
> But I could still use session.getTransaction() and get the
“wrong”
> behavior?
>
I think it's the general question should we have an API which offers
"everything", i.e. the sum of all functionality of all backends, meaning
that some parts of the announced API functionality will fail at runtime
(either silently or with an exception) on some backends. Or should we have
a more limited API which is supported everywhere, and then allow to
"unwrap" for certain backends (or families) and access advanced
functionality just applying to those (as we e.g. do with the configuration
API).
Currently OgmSession is the former, i.e. you could invoke getTransaction()
and basically achieve the same as with the proposed alternative. But you
could also try to rollback() and then it would fail, depending on the store.
I feel like the latter a bit better. For that we'd need a more limited
OgmSession contract, not extending ORM's Session. This could e.g. host the
runWorkUnit() functionality which is portable across backends.
Then there could be something like
OgmSession.as(TransactionalSession.class).beginTransaction(). Here you
would explicitly opt into transactional functionality. Of course you still
could wrongly invoke this e.g. for MongoDB, but IMO it can be documented in
a better way and help to manage people's expectations towards supported
functionality. Or, e.g. with CDI it could even fail right at deploy of no
TransactionalSession bean can be produced as per the current backend.
I am not sure how you reconcile that with the idea that OGM is a JPA
persistence provider implementation that integrates with things like app
servers and that these guys do use the `EntityManager` API. Will you forbid
app servers to expose rollback on the JTA APIs? And to inject a
`EntityManager` and force an `OgmEntityManager`?