Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Andy Jefferson <andy@datanucleus.org>
To: jdo-dev@db.apache.org
Subject: Re: svn commit: r1148192 -
 /db/jdo/trunk/tck/src/conf/jdori-pmf.properties
Date: Wed, 10 Aug 2011 05:20:47 +0100
User-Agent: KMail/1.12.4 (Linux/2.6.31.13-desktop-1mnb; KDE/4.3.5; i686; ; )
References: <4E26FD63.4050706@akquinet.de> <4E419929.5050008@akquinet.de>
 <81A80B80-3E0A-4DB4-AB2A-11E61E815173@oracle.com>
In-Reply-To: <81A80B80-3E0A-4DB4-AB2A-11E61E815173@oracle.com>
Organization: DataNucleus
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201108100520.47642.andy@datanucleus.org>

> The intent of the "increment" strategy is to allow use of a database
> that the user has no control over (for example, the DBA refuses to add
> new tables). It's not an optimal strategy but a useful one. The JDO
> implementation can cache the largest key used and mitigate database
> access for each insert.
> 
> But without changing the specification, I don't think it's ok to
> require another table in order to implement "increment". That's what
> "sequence" is for.
> 
> Was there a recent change in DataNucleus that now "increment" is
> implemented using an internal "sequence" strategy?

DataNucleus simply changed to make use of the "autoCreate" flags in imposing 
whether it was allowed to create *any* schema components. It has ALWAYS used a 
table for "increment", that is not a change. "sequence" has always been to use 
a datastore sequence also.


-- 
Andy
DataNucleus (http://www.datanucleus.org)