Mike, Thanks. That's my exact point. We have a heirarchy defined by the spec. We first have the POJO source code, then we have annotations (which should override the POJO source code), and then we have the orm.xml that trumps the annotations. So, to ignore the annotation request to generate the values because we have attempted to detect an alternate means of assigning values (initial values, calling the setter, etc) doesn't seem right. And, the same argument applies to the orm.xml overrides. The whole idea of the orm.xmlfile is to allow the specification of the o/r mappings independent of the source code. No re-compliing or re-building should be necessary. Just update the orm.xml and change the behavior. But, if the source code used the setter methods for the values (possibly as test code), we shouldn't override that via the orm.xml settings? Doesn't sound right...
I would like to close on this issue. I think the @GeneratedValue (and the associated orm.xml element) should override any initial value or setter method invocations. That would be the most straight forward and easiest to explain to our customers. I'm not understanding the benefit of allowing the code to override the @GeneratedValue request. Thanks, Kevin On 7/5/07, Michael Dick <[EMAIL PROTECTED]> wrote:
What happens if there isn't a GeneratedValue annotation, but there is one in orm.xml? In that case shouldn't the generated values take precedence? On 7/5/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: > > 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 > > >
