+1 for a strategy - that also allows to do a faster check against the @Version property (if available). -1 for any split (we already separated the data-module from the jpa-module due to its complexity).
regards, gerhard 2015-08-14 15:33 GMT+02:00 Marvin Toll <marvint...@gtcgroup.com>: > Sounds good... perhaps obviously I'm a DeltaSpike newbie and negotiating > my way through the learning curve. > > -----Original Message----- > From: Karl Kildén [mailto:karl.kil...@gmail.com] > Sent: Friday, August 14, 2015 8:00 AM > To: dev@deltaspike.apache.org; marvint...@gtcgroup.com > Subject: Re: Issues with EntityRepository.save() > > Marvin, > > What you are suggesting is not required imo. Some strategy configuration > like suggested from Thomas would give the same benefits. > > On 14 August 2015 at 13:39, Marvin Toll <marvint...@gtcgroup.com> wrote: > > > <Harald> At the moment, I don't see a way to specify and implement > > save() in a way that is logically consistent *and* portable across JPA > providers. > > (I'll be happy to be proved false.) > > </Harald? > > > > Had another idea just before drifting off to sleep last night... > > perhaps this dreamy though is useful for consideration in the light of > day? > > > > What if--- > > > > DeltaSpike DataH[impl only] (the current DeltaSpike Data) was > > optimized for Hibernate? > > > > And a new DeltaSpike DataE[impl only] was optimized for EclipseLink? > > > > > > Said another way, an objective of trying to abstract both of these > > provides, given the large volume of custom extensions required for a > > still too immature JPA specification, and perhaps more importantly > > maintain an adequate Test Suite(s), may be more challenging/limiting > > than first imagined? > > > > > > _Marvin > > > > >
