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 plinskey@gmail.com designates
 64.233.166.182 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:content-transfer-encoding:content-disposition:references;
        b=nn/8J82cC0rUlMfKI15WsHZynTG4CHLv+8ozUlJllU0NzUW+42EIfFvzFSR6hqXHjXaKB78XcLFbp1XzOzpG5KlETS360JkncI/D4ThON2a4c7qL0xA495J1qktiZIx28hx5tOSTfTwhiOCbOmTICAkjzXesey1D3UFan2O4W3k=
Message-ID: <7262f25e0707101450m388389eap2d439130f43b2c56@mail.gmail.com>
Date: Tue, 10 Jul 2007 14:50:53 -0700
From: "Patrick Linskey" <plinskey@gmail.com>
To: dev@openjpa.apache.org
Subject: Re: Allow overrides of @GeneratedValue?
In-Reply-To: <89c0c52c0707101419r312a057bpd629cdb0c13df243@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>
	 <89c0c52c0707101419r312a057bpd629cdb0c13df243@mail.gmail.com>

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

I would argue that we do not need to support
generated-values-by-default, overriding-by-setting-field,
un-overriding as a use case.

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

I don't like the idea of silently changing the user-specified values.
That seems really dangerous. I understand that we may need to make
accommodations for initial values, given how they are implemented, but
I think that we should definitely not do silent-ignoring of calls to
set the value after the instance has been associated with a Broker.

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


-- 
Patrick Linskey
202 669 5907