[
https://issues.apache.org/jira/browse/JDO-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092878#comment-13092878
]
Matthew T. Adams commented on JDO-683:
--------------------------------------
For the @Version annotation, that's what I had intended to say. See my second
paragraph ("attribute" refers to both field & property). I like your
suggestion of allowing <version> to go under <field> or <property> better than
mine. We'll have to validate the metadata, however, so that the user doesn't
specify it both at the class level & the field/property level.
The proposed PMF & PM property controlling the behavior on setting the version
attribute was discussed on the conf call, because the user is not supposed to
write to that field. As such, we felt we would disallow it by default, but
still allow knowledgeable applications to write the version attribute if they
knew how their implementation would handle that situation.
> Allow version field/property to be visible to application
> ---------------------------------------------------------
>
> Key: JDO-683
> URL: https://issues.apache.org/jira/browse/JDO-683
> Project: JDO
> Issue Type: Improvement
> Components: api
> Affects Versions: JDO 3 maintenance release 1
> Reporter: Matthew T. Adams
> Labels: jdo, jdouserexception, optimistic, transactions, version
>
> Currently, it requires a vendor extension to make the version attribute
> (field or property) of a PC visible to the application. Some knowledgeable
> applications may need not only read access to the version field, but also
> write access to it.
> I propose that we allow version metadata to specify that a version attribute
> be application-visible. For annotation-based metadata, I recommend that it
> be allowed to be placed on fields & methods. For XML metadata, add XML
> attributes "attribute-name" to the "version" element that allows the user to
> specify which field or property is to hold the application-visible version
> value.
> Along with this change would be verbiage in the spec noting that applications
> really shouldn't change this value, but a knowledgeable application may
> change it, based on a new PMF & PM property called something like
> "javax.jdo.option.OnVersionChangeByApplication" with the following specified
> values.
> THROW: (default) the implementation will throw JDOUserVersionChangeException
> (extends JDOUserException) as early as the time the value is set, at the next
> flush, or at commit.
> IGNORE: the implementation ignores the value the user set for the object's
> version
> ALLOW: the implementation allows and uses the value the user set for the
> object's version
> This allows users to who know how their implementation behaves on
> user-modified version values to take advantage of such behavior.
> All names proposed are up for discussion.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
