JDO
  1. JDO
  2. JDO-683

Allow version field/property to be visible to application

    Details

      Description

      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.

        Activity

        Hide
        Andy Jefferson added a comment -

        Or you simply allow @Version to be specifiable on the field/property, and <version> be specified under <field>/<property>

        Show
        Andy Jefferson added a comment - Or you simply allow @Version to be specifiable on the field/property, and <version> be specified under <field>/<property>
        Hide
        Matthew T. Adams added a comment -

        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.

        Show
        Matthew T. Adams added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            Matthew T. Adams
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development