Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (herse.apache.org: domain of kwsutter@gmail.com designates
 209.85.146.181 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=gNUQ0VnnSntbraZbgUAvcVWHb6+fHYoP6KryvgIYHnFq9ggtMKUYApfBn3ip076D1Fm8TxMiADHb/jKOZh9mT8MUohsHcB+XL1SGFMq56hZNS31gLdJiEQyyOrN1rcfn/i8q0LlJP0+9SC9CNNOpyi+dvZBao1xQF/KOkvyeOEA=
Message-ID: <89c0c52c0707101419r312a057bpd629cdb0c13df243@mail.gmail.com>
Date: Tue, 10 Jul 2007 16:19:21 -0500
From: "Kevin Sutter" <kwsutter@gmail.com>
To: dev@openjpa.apache.org
Subject: Re: Allow overrides of @GeneratedValue?
In-Reply-To: <7262f25e0707101008x700e7addk595b840b48e8e0fc@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_147160_18559012.1184102361321"
References: <89c0c52c0707051003h6c80cfeemf6b44794a774ae20@mail.gmail.com>
	 <7262f25e0707051055t52ecec4at161e8a41512e0e58@mail.gmail.com>
	 <89c0c52c0707051138n20b5a390k842af4dfba58f219@mail.gmail.com>
	 <72c1350f0707051231m6ef5d781nb894e0f0a37ca21c@mail.gmail.com>
	 <89c0c52c0707100839o7aa272bfnbd574782f65831ce@mail.gmail.com>
	 <7262f25e0707101008x700e7addk595b840b48e8e0fc@mail.gmail.com>

------=_Part_147160_18559012.1184102361321
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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


Good.  What I am trying to get to is what the proper behavior should be.
Right now, the current code does not work.  If you attempt to use initial
values when declaring the fields that are supposed to be auto generated, you
will only get that initial value for the field.  This results in the dup key
exceptions I mentioned earlier.  OPENJPA-272 has more details.

And, if we are allowing the use of setter methods, where is this ability
documented?  And, are we supposed to set the value to 0 or null to force us
to start generating values again?  Seems kind of awkward.

This just seems like something that is accidentally working under certain
circumstances.  Do we really want to bend over backwards to get these edge
cases supported?  Or, should we declare that auto generated means auto
generated and not allow the initial values or the use of setter methods?  If
you can't tell, that's my preference.

I hate to throw an exception in this case.  If the initial values or setter
invocations were there for scaffolding or testing, I would like the use of
the annotations or xml to override and continue execution.  Exceptions would
disrupt that flow.  An informational message might be okay, but even then we
might fill up a log with messages (depending on the application).

Sounds like we need a compromise here somewhere.  I need to get auto
generation to work.  How about if I go ahead with the auto generation
enforcement?  I will also fix up the testcase that is currently depending on
this "errant" behavior.  I will also provide a new testcase that
demonstrates we have these situations working.  And, I will create a new
sub-task for a possible error/exception to be logged if the code attempts to
override the auto generation.  I'm not convinced that we want to report this
as a problem to the running code, so I figure a new Issue would at least
document the request.

Other thoughts?

Thanks,
Kevin


-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
>

------=_Part_147160_18559012.1184102361321--