imo the next step is to add an optional check for the @Version property. for other special cases it should be enough to document the customization with QueryInvocationContext.
regards, gerhard 2015-08-22 1:46 GMT+02:00 Marvin Toll <marvint...@gtcgroup.com>: > First an FYI... the Ford Motor Company Intellectual Property attorney > group approved our (ten specifically named Software Engineers) > participation with the Apache DeltaSpike community yesterday. So, we can > now use the word "Ford" in our informal communications. :-) > > This does not represent a formal endorsement of DS nor does it give > license for the use/misuse of the "Ford" brand in any formal communications. > > In any case, we are continuing to develop use cases using the "save" > method in combination with EclipseLink (only). We may have found a > 'broken" scenario today but plan to verify this on Monday with fresh eyes > to see whether this is truly a "bug"... and worth pursing as a > representative case of "unexpected" behavior using the "save" abstraction. > > Our strategy includes, running a scenario with native JPA (EclipseLink) > and then the same scenario with DS Data... and looking for different > outcomes. > > Bottom line? I agree with John that this discussion needs attention. > > More to come, > Marvin > > -----Original Message----- > From: John D. Ament [mailto:johndam...@apache.org] > Sent: Friday, August 21, 2015 5:22 PM > To: dev@deltaspike.apache.org; Marvin Toll <marvint...@gtcgroup.com> > Subject: Re: Issues with EntityRepository.save() > > 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 > > > >> > <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> > > >> > > > >
