openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <michael.d.d...@gmail.com>
Subject Re: Allow overrides of @GeneratedValue?
Date Thu, 05 Jul 2007 19:31:54 GMT
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 <kwsutter@gmail.com> 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 < plinskey@gmail.com> wrote:
> >
> > > Thoughts?
> >
> > Spec interpretation aside, I like our current behavior -- it seems
> > nice and intuitive.
> >
> > -Patrick
> >
> > On 7/5/07, Kevin Sutter < kwsutter@gmail.com> 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message