Hi,
So if we introduce a flag that uses the same instance on attach, we
might want to have the flag called CopyOnMakePersistent and have
true be the current specified behavior and false be the new
behavior we've been discussing.
Sounds great to me. There's some fine print here, though:
CopyDetachedOnMakePersistent?
Craig
On Aug 8, 2007, at 11:31 PM, Andy Jefferson wrote:
Hi,
So if we introduce a flag that uses the same instance on attach, we
might want to have the flag called CopyOnMakePersistent and have
true be the current specified behavior and false be the new
parameters to makePersistent() when
DetachAllOnCommit=true
CopyDetachedOnMakePersistent?
Craig
On Aug 8, 2007, at 11:31 PM, Andy Jefferson wrote:
Hi,
So if we introduce a flag that uses the same instance on attach, we
might want to have the flag called CopyOnMakePersistent and have
true
exhaustive...me no
likey.
-matthew
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 09, 2007 8:07 AM
To: Andy Jefferson
Cc: jdo-dev@db.apache.org; JDO Expert Group
Subject: Re: 2.1 Spec: detached-dirty parameters to makePersistent
() when
So if we introduce a flag that uses the same instance on attach, we
might want to have the flag called CopyOnMakePersistent and have true
be the current specified behavior and false be the new behavior we've
been discussing.
The defaults for these kinds of options have never been specified
On Aug 8, 2007, at 7:29 PM, Craig L Russell wrote:
So if we introduce a flag that uses the same instance on attach, we
might want to have the flag called CopyOnMakePersistent and have
true be the current specified behavior and false be the new
behavior we've been discussing.
Sounds
Hi Chris,
On Aug 8, 2007, at 8:07 PM, cbeams wrote:
P.S.: When sending emails of this sort, should I always cc the jdo-
[EMAIL PROTECTED] address, or is jdo-dev sufficient?
You should send messages to both jdo-experts and jdo-dev aliases. One
of them is the official expert group and the
On Aug 7, 2007, at 11:35 AM, Andy Jefferson wrote:
You could allow something of this form by imposing a restriction
that if an
object needs attaching, and that AttachOnPersist flag is set, and
the PM
already has a persistent object with that id then throw a
JDOUserException.
Clearly the
With this restriction in place, however, would I be able to do the
following?
// fetch a detched object
Query q = pm.newQuery(Foo.class);
q.setUnique(true);
Foo foo = (Foo) q.execute();
detachAllOnCommit will transition instances to detached *at commit*. You
have no commit here (using
On Aug 7, 2007, at 12:11 PM, Andy Jefferson wrote:
With this restriction in place, however, would I be able to do the
following?
// fetch a detched object
Query q = pm.newQuery(Foo.class);
q.setUnique(true);
Foo foo = (Foo) q.execute();
detachAllOnCommit will transition instances to
// and attach it a second time
foo : detached-dirty - persistent-clean
I'm with you until this last one... It would transition from
persistent-clean to detached-clean upon committing the transaction,
right? If so, then we're aligned...
Yes.
It's the same operation as earlier, so it
My previous email on this topic was a bit verbose, and I later
realized contained some inaccuracies. Keeping things as succinct as
possible, is there any reason the spec couldn't be amended to support
the following code?
package com.xyz;
import org.apache.log4j.Logger;
import
12 matches
Mail list logo
