[
https://issues.apache.org/jira/browse/OPENJPA-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510456
]
Kevin Sutter commented on OPENJPA-272:
--------------------------------------
It's turning out that this is more than just autoboxing. The setting of
initial values for fields annotated with @GeneratedValue is causing several
problems.
For example, even if I have the same types through the Entity definition (where
autoboxing does not come into play)...
private Long id = new Long(5);
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
.. I still get the duplicate key exceptions because our runtime logic doesn't
know the difference between the initial value and somebody setting a value. As
I pointed out in a separate mail thread, the invocation of the setter method
was also being allowed to override the @GeneratedValue annotation. And, once
you have set your own id, how do you tell OpenJPA "okay, I'm done now... go
ahead and generate the rest of the ids now..."?
It just seems like we're opening a can of worms attempting to support both
ways. I think the @GeneratedValue annotation should take precedence.
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.
