Return-Path: 
 <jdo-dev-return-9131-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org>
X-Original-To: apmail-db-jdo-dev-archive@www.apache.org
Delivered-To: apmail-db-jdo-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id D34267405
	for <apmail-db-jdo-dev-archive@www.apache.org>;
 Mon, 29 Aug 2011 13:12:00 +0000 (UTC)
Received: (qmail 48723 invoked by uid 500); 29 Aug 2011 13:12:00 -0000
Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:jdo-dev-help@db.apache.org>
List-Unsubscribe: <mailto:jdo-dev-unsubscribe@db.apache.org>
List-Post: <mailto:jdo-dev@db.apache.org>
List-Id: <jdo-dev.db.apache.org>
Reply-To: jdo-dev@db.apache.org
Delivered-To: mailing list jdo-dev@db.apache.org
Received: (qmail 48715 invoked by uid 99); 29 Aug 2011 13:11:59 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Aug 2011 13:11:59 +0000
X-ASF-Spam-Status: No, hits=-2000.5 required=5.0
	tests=ALL_TRUSTED,RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Aug 2011 13:11:57 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id B773AD5484
	for <jdo-dev@db.apache.org>; Mon, 29 Aug 2011 13:11:37 +0000 (UTC)
Date: Mon, 29 Aug 2011 13:11:37 +0000 (UTC)
From: "Andy Jefferson (JIRA)" <jira@apache.org>
To: jdo-dev@db.apache.org
Message-ID: 
 <888272842.3077.1314623497748.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <2141193802.18329.1314378809023.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (JDO-683) Allow version field/property to be
 visible to application
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/JDO-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092825#comment-13092825 ] 

Andy Jefferson commented on JDO-683:
------------------------------------

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

> 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