openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: Allow overrides of @GeneratedValue?
Date Tue, 10 Jul 2007 15:39:37 GMT
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 <michael.d.dick@gmail.com> 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 <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