openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From plins...@gmail.com
Subject Re: Allow overrides of @GeneratedValue?
Date Tue, 10 Jul 2007 17:08:29 GMT
I think that the benefit is that it let's the user code take control
when it wants / needs to.

Certainly, the behavior should be (and is currently) the same for
annotations and XML.

If we do decide that generated values should not be user-settable,
then we must guarantee this in code with a good exception.

-Patrick

On 7/10/07, Kevin Sutter <kwsutter@gmail.com> wrote:
> 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
> > > >
> > >
> >
>


-- 
Patrick Linskey
202 669 5907

Mime
View raw message