Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 85923 invoked from network); 7 Aug 2007 18:51:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Aug 2007 18:51:23 -0000 Received: (qmail 25356 invoked by uid 500); 7 Aug 2007 18:51:22 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 25324 invoked by uid 99); 7 Aug 2007 18:51:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Aug 2007 11:51:21 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of cbeams@gmail.com designates 209.85.162.183 as permitted sender) Received: from [209.85.162.183] (HELO el-out-1112.google.com) (209.85.162.183) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Aug 2007 18:51:16 +0000 Received: by el-out-1112.google.com with SMTP id b25so312464elf for ; Tue, 07 Aug 2007 11:50:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:from:subject:date:to:x-mailer; b=jcAlOE6H3NX6Z/AuQfbUmW5xLfIRhc0s6GBwWFCDSwgejqN09Aa2JMbCXPr9QNrb1XZ+lhzotqqk/U3OikOCREXsNFyi58JoLI+AWgykm3412MntCouwJHkbwQvh0uUhGgW7RZQJ2jGuKlGcZWFEhR8pZCvvKWLfgimr6RYTvzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:from:subject:date:to:x-mailer; b=nMAw+wt8Vj9VZMXzWJJ/+wETb1GDvR0IYwmjBdd4t5ogRABNemtEbu5dnGtVlaY/HRPgmbjEEv4Ibsm7RNjduIT+2goR91sd1cqcl2I2Ogfu0FFZvDGfMfc4njszumcaI4o3+2Kr6Ajp4JskINBaUmDAiaqtpmWdEe2OTXsng0s= Received: by 10.100.128.8 with SMTP id a8mr4094210and.1186512655210; Tue, 07 Aug 2007 11:50:55 -0700 (PDT) Received: from ?10.5.15.101? ( [209.133.30.215]) by mx.google.com with ESMTPS id c37sm9327233ana.2007.08.07.11.50.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Aug 2007 11:50:54 -0700 (PDT) In-Reply-To: <200708071935.31790.andy@jpox.org> References: <45CA023F-9583-4BA6-BD8F-1A2F7149F5C2@gmail.com> <327A6464-2DF1-482A-8342-6E931DD9B48A@gmail.com> <200708071935.31790.andy@jpox.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-116--100389044 Message-Id: Cc: JDO Expert Group From: cbeams Subject: Re: 2.1 Spec: detached-dirty parameters to makePersistent() when DetachAllOnCommit=true Date: Tue, 7 Aug 2007 11:52:04 -0700 To: jdo-dev@db.apache.org X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-116--100389044 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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 primary use-case is where the user detaches a single > object, and > then wants to attach the same thing, so they typically never hit the > duplicate detached object issue. You're right about the primary use case. With this restriction in place, however, would I be able to do the following? import static javax.jdo.JDOHelper.*; assert pm.getAttachOnPersist() == true; assert pm.getDetachAllOnCommit() == true; // fetch a detched object Query q = pm.newQuery(Foo.class); q.setUnique(true); Foo foo = (Foo) q.execute(); // my foo object is now detached-clean assert isDetached(foo) && !isDirty(foo); // make it dirty: foo.setBar("bar"); // attach pm.currentTransaction().begin(); pm.makePersistent(foo); pm.currentTransaction().commit(); // should be transitioned back to detached-clean assert isDetached(foo) && !isDirty(foo); // dirty it once more foo.addBaz("baz"); // and attach it a second time - wouldn't this cause the JDOUserException you mention above? The pm is already managing (by ID, I assume) this object, so how would it know the difference between the application 'detaching and attaching two separate instances of the same object' and simply 'attaching twice the same instance of an object'? Hopefully I'm missing something, because I like the proposed solution. pm.currentTransaction().begin(); pm.makePersistent(foo); pm.currentTransaction().commit(); // again, should now be detached-clean assert isDetached(foo) && !isDirty(foo); - Chris --Apple-Mail-116--100389044--