From jdo-dev-return-4677-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org Wed Jul 12 17:37:49 2006 Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 23217 invoked from network); 12 Jul 2006 17:37:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Jul 2006 17:37:49 -0000 Received: (qmail 8578 invoked by uid 500); 12 Jul 2006 17:37:49 -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 8563 invoked by uid 99); 12 Jul 2006 17:37:49 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jul 2006 10:37:49 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [80.67.18.43] (HELO smtprelay05.ispgateway.de) (80.67.18.43) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jul 2006 10:37:47 -0700 Received: (qmail 15705 invoked from network); 12 Jul 2006 17:37:24 -0000 Received: from unknown (HELO [192.168.100.11]) (383542@[195.143.217.178]) (envelope-sender ) by smtprelay05.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 12 Jul 2006 17:37:24 -0000 Message-ID: <44B53359.5010500@artnology.com> Date: Wed, 12 Jul 2006 19:37:29 +0200 From: =?ISO-8859-1?Q?J=F6rg_von_Frantzius?= Organization: artnology GmbH, Berlin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: jdo-dev@db.apache.org CC: JDO Expert Group Subject: Re: Behavior of deletePersistent with datastore constraints References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------010708040203090902070504" X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --------------010708040203090902070504 Content-Type: multipart/alternative; boundary="------------030202090502010307060104" --------------030202090502010307060104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hello Craig, please see my comments below... Craig L Russell schrieb: [..] > I'd like to discuss the two items above. The spec requires that > deletes be deferred until flush, but I suspect that this > overconstrains the possible implementations. I would leave it up to > the implementation to decide whether to delete immediately or defer > until flush. > > But if it deletes the instance immediately, it would also have to > nullify any foreign keys that refer to it in order to avoid an > immediate constraint violation. And I don't believe that this should > be done automatically unless the user specifically asked for it, via a > metadata annotation on the Why would we like to avoid immedate constraint violations in the first place? They only constrain the user in that that he/she has to remove objects from any associations before being able to delete them, and not afterwards. Alternatively, if the user finds that uncomfortable, he could make those FKs deferrable (if the DB allows it). > foreign key delete-action=NULL. If the implementation wanted to > nullify the referring key where the constraint was defined as anything > else, it would have to guarantee at flush time that the user had set > the field to null or something else, or all the referring objects > themselves were deleted. That sounds really very complicated. I'd wonder why someone would take on the effort only to mimic real deferred constraints (for the case of deletion only). > > With regard to integrity constraints, the second paragraph leaves me > cold. I don't know what I was thinking when I wrote "or the delete > operation is simply ignored". When would ignoring a delete from the > application ever be the right behavior? That's what I had been wondering as well! Regards, Jörg > > Comments? > > Craig Russell > > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > > 408 276-5638 mailto:Craig.Russell@sun.com > > P.S. A good JDO? O, Gasp! > > --------------030202090502010307060104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Craig,

please see my comments below...

Craig L Russell schrieb:

[..]
I'd like to discuss the two items above. The spec requires that deletes be deferred until flush, but I suspect that this overconstrains the possible implementations. I would leave it up to the implementation to decide whether to delete immediately or defer until flush. 

But if it deletes the instance immediately, it would also have to nullify any foreign keys that refer to it in order to avoid an immediate constraint violation. And I don't believe that this should be done automatically unless the user specifically asked for it, via a metadata annotation on the
Why would we like to avoid immedate constraint violations in the first place? They only constrain the user in that that he/she has to remove objects from any associations before being able to delete them, and not afterwards. Alternatively, if the user finds that uncomfortable, he could make those FKs deferrable (if the DB allows it).
foreign key delete-action=NULL. If the implementation wanted to nullify the referring key where the constraint was defined as anything else, it would have to guarantee at flush time that the user had set the field to null or something else, or all the referring objects themselves were deleted.
That sounds really very complicated. I'd wonder why someone would take on the effort only to mimic real deferred constraints (for the case of deletion only).

With regard to integrity constraints, the second paragraph leaves me cold. I don't know what I was thinking when I wrote "or the delete operation is simply ignored". When would ignoring a delete from the application ever be the right behavior?
That's what I had been wondering as well!

Regards,
Jörg

Comments?

Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 mailto:Craig.Russell@sun.com

P.S. A good JDO? O, Gasp!



--------------030202090502010307060104-- --------------010708040203090902070504--