Good suggestion!
Trying to figure out what "save" does in all contexts has been a challenge...
and those that know native JPA are familiar with these seven often used methods:
clear()
contains()
detach()
flush()
merge()
persist()
remove()
If these methods exercise the underlying provider implementation directly, that
is as forwarding methods, then perhaps the "save" methods could be deprecated
so they no longer 'add' to the JPA API learning curve and potentially are a
source of confusion?
------------------------------------------
There has been a second area of confusion.
Our current theory is that when using Request Scoped transactions the Flush is
required when subsequent processing occurs after a transaction (but before the
end of the Request).
However, when using Transaction Scoped transactions the flush is not required.
Therefore, when changing declarative scope a corresponding programmatic change
is required. We plan to verify this accuracy of this theory in multiple
functional contexts next week.
------------------------------------------
Realize that our team learning context is as users of persistence (Toplink) for
ten+ years and native JPA (EclipseLink) for a couple of years.
Thus, some confusion is to be expected when determining how the DS abstraction
interacts with EclipseLink.
_Marvin
-----Original Message-----
From: John D. Ament [mailto:[email protected]]
Sent: Friday, August 21, 2015 9:23 PM
To: deltaspike <[email protected]>
Subject: [DISCUSS] Add persist and merge methods to EntityRepository
All,
Based on the findings from Harald, and the general issues being seen with
EntityRepository I'd like to propose that we add merge and persist methods to
the EntityRepository interface.
Both methods would delegate down direct to the underlying EntityManager's
methods of the same signature and have the exact same behavior. This will give
app developers direct access in cases where they want to explicitly call one or
the other.
John
