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> > >> >
