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:johndam...@apache.org] Sent: Friday, August 21, 2015 9:23 PM To: deltaspike <dev@deltaspike.apache.org> 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