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 >
