So the discussions on this died down, but I think we should still plan to do something regarding the issue.
I'd like to propose that we do #1 and the back half of #4. We may want to add some additional comments. For example, recommend that the @Id column is always nullable, which should clarify some of the behavior. We may even want to try to add a log message around it. I'm going to try to add nullable IDs to the project I'm working on right now to see if it works the way I expect. If so would be the right way to go IMHO for users in general. Another issue I noticed with EntityRepository is that I can extend it with EntityRepository<Pojo,String> where String is not the @Id column. There are absolutely no warning about this, and you wouldn't notice the issue until you try calling findBy(PK). May want to add a note about this as well, even if its only in dev mode. John On Mon, Aug 17, 2015 at 2:43 PM Gerhard Petracek <gerhard.petra...@gmail.com> wrote: > 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 > >> > > >> > >> > >> > > >
