openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-272) @GenerateValue (AUTO) doesn't work with Property level access
Date Sun, 05 Aug 2007 23:59:29 GMT

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


Mime
View raw message