[
https://issues.apache.org/jira/browse/OPENJPA-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517801
]
Kevin Sutter commented on OPENJPA-272:
--------------------------------------
I just committed the changes to resolve this issue. Per the discussion on our
dev mailing list
(http://www.nabble.com/Allow-overrides-of-%40GeneratedValue--tf4031013.html#a11450606),
I decided to go with the more direct response as Patrick and others suggested.
That is, if somebody has @GeneratedValue on a field (id or otherwise) and then
attempts to set a value either via an initializer or a setter method, then an
InvalidStateException will be thrown. This will immediately let the user know
that something isn't quite right. At first, I thought this was too drastic and
was leaning towards a warning or error message. But, due to data integrity
concerns, I decided to go with an exception to signal the problem. This will
force the user to do something about the situation instead of blindly running
with it until s/he notices the error message.
The exception thrown has a localizer message that indicates the problem and
suggested actions to resolve it.
I also provided a new testcase to test for this new condition and the exception
processing.
I also had to update the TestSharedMappedSuperclassIdValue testcase since it
was incorrectly relying on this "incorrect" behavior.
Kevin
> @GenerateValue (AUTO) doesn't work with Property level access
> -------------------------------------------------------------
>
> Key: OPENJPA-272
> URL: https://issues.apache.org/jira/browse/OPENJPA-272
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 0.9.7
> Reporter: Kevin Sutter
> Assignee: Kevin Sutter
> Fix For: 1.0.0
>
>
> The @GenerateValue annotation doesn't work correctly when applied to via the
> Property level access (getter method) when using the wrapper classes for the
> primitive types. Something like this:
> private Long id;
> @Id
> @GeneratedValue(strategy=GenerationType.AUTO)
> public Long getId() {
> return id;
> }
> public void setId(Long id) {
> this.id = id;
> }
> With this type of Entity definition, we hit a problem when checking for the
> "default value":
> public boolean isDefaultValue() {
> return dblval == 0 && longval == 0
> && (objval == null || "".equals(objval));
> }
> For this scenario, objval is not null and it's not of type String, so we fail
> this test and return false. Upon returning the value of false, the calling
> code skips the call that would have assigned the generated value to the field
> (in ApplicationIds):
> private static boolean assign(OpenJPAStateManager sm, StoreManager store,
> FieldMetaData[] pks, boolean preFlush) {
> for (int i = 0; i < pks.length; i++)
> if (pks[i].getValueStrategy() != ValueStrategies.NONE
> && sm.isDefaultValue(pks[i].getIndex())
> && !store.assignField(sm, pks[i].getIndex(), preFlush))
> return false;
> return true;
> }
> I haven't figured out the exact fix yet, but there are two workarounds
> available:
> 1. Use field level annotations instead of property, or...
> 2. Don't use the primitive wrapper types (use long instead of Long).
> In either of these cases, objval is left as null and we are eventually
> allowed to call store.assignField() which gets the generated value assigned
> to the field in question (id in this case).
> I will keep digging, but if anyone knows the history of the isDefaultValue()
> method, it would help with getting a quick answer to this Issue. Since we're
> dealing with generated values, I'm not clear why we care if values are
> already assigned to this field or not. It would seem that we would want to
> just override what's there. But, like I said, I need to dive into this a
> bit. I just wanted to get the Issue on the books with the information I
> discovered thus far.
> Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
