You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Kevin Sutter <kw...@gmail.com> on 2007/07/05 19:03:21 UTC
Allow overrides of @GeneratedValue?
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
Re: Allow overrides of @GeneratedValue?
Posted by Patrick Linskey <pl...@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 <kw...@gmail.com> wrote:
> On 7/10/07, plinskey@gmail.com <pl...@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 <kw...@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 <mi...@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 <kw...@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
Re: Allow overrides of @GeneratedValue?
Posted by Kevin Sutter <kw...@gmail.com>.
On 7/10/07, plinskey@gmail.com <pl...@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 <kw...@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 <mi...@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 <kw...@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
>
Re: Allow overrides of @GeneratedValue?
Posted by pl...@gmail.com.
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 <kw...@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 <mi...@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 <kw...@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
Re: Allow overrides of @GeneratedValue?
Posted by Kevin Sutter <kw...@gmail.com>.
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 <mi...@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 <kw...@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
> > >
> >
>
Re: Allow overrides of @GeneratedValue?
Posted by Michael Dick <mi...@gmail.com>.
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 <kw...@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
> >
>
Re: Allow overrides of @GeneratedValue?
Posted by Kevin Sutter <kw...@gmail.com>.
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 <pl...@gmail.com> wrote:
>
> > Thoughts?
>
> Spec interpretation aside, I like our current behavior -- it seems
> nice and intuitive.
>
> -Patrick
>
> On 7/5/07, Kevin Sutter <kw...@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
>
Re: Allow overrides of @GeneratedValue?
Posted by Patrick Linskey <pl...@gmail.com>.
> Thoughts?
Spec interpretation aside, I like our current behavior -- it seems
nice and intuitive.
-Patrick
On 7/5/07, Kevin Sutter <kw...@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