i just thought about how we could call such a strategy and saw that we don't need it imo. QueryInvocationContext is already a spi -> just provide a specialized version of org.apache.deltaspike.data.impl.handler.CdiQueryInvocationContext (or a global alternative) or use a decorator and override #isNew.
regards, gerhard 2015-08-14 16:12 GMT+02:00 Gerhard Petracek <gerhard.petra...@gmail.com>: > +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 >> > >> >> >> >
