Personally, I don't find the current behavior intuitive. I find it counter-intuitive. For this scenario, I have included an annotation that says to please generate values for my id fields. But, then I am allowed to set values for the keys? It seems that once we have indicated a desire to have the fields auto-generated, then that's what should take precedence.
Kevin On 7/5/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
> Thoughts? Spec interpretation aside, I like our current behavior -- it seems nice and intuitive. -Patrick On 7/5/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: > Hi, > Looking for some input for OPENJPA-272. > > Should we allow an application to override the @GeneratedValue annotation? > For example, consider the following code snippet... > > @Id > @GeneratedValue(strategy=GenerationType.AUTO) > private long id; > > Given this, should an application be allowed to use the setter method (call > setId(100)) or provide an initial value (private long id = 100;) to override > the intent of the annotation? The spec is not 100% clear on this. Mike > Keith's book has a statement on page 83: > > "When id generation is enabled, the persistence provider will generate an > identifier value for every entity instance of that type." > > If you've been following my OPENJPA-272 JIRA report, I think we have a bug > in our runtime where we allow this override to happen. My take is that the > annotation is now dictating the values for this field and the application > should no longer have a say in the values. > > Of course, when I make this type of change to enforce the GeneratedValue > idea, one of our testcases (TestSharedMappedSuperclassIdValue) has relied on > this override behaviour and now fails. Looking at the testcase, I think it > wanted to use the same id value, but the "wrong" Entity classes were used to > test with. Either this testcase should use alternate Entities without the > @GeneratedValue annotation, or change the testcase to not care about the id > values and let them get generated. > > Thoughts? > > Kevin > -- Patrick Linskey 202 669 5907
