Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 5 Nov 2013 18:41:18 +0000 (UTC)
From: "Mike Matrigali (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12313704.1124846280000.23577.1383676878088@arcas>
In-Reply-To: <JIRA.12313704.1124846280000@arcas>
References: <JIRA.12313704.1124846280000@arcas>
Subject: [jira] [Commented] (DERBY-532) Support deferrable constraints
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-532?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13814=
109#comment-13814109 ]=20

Mike Matrigali commented on DERBY-532:
--------------------------------------

can anyone speak to whether deferred constraint checking is in anyway simil=
ar to deferred updates already supported in the sql layer of the derby code=
.  Is there anyway to use that existing code to batch up a set of
changes and run deferred constraint checking at given time?

> Support deferrable constraints
> ------------------------------
>
>                 Key: DERBY-532
>                 URL: https://issues.apache.org/jira/browse/DERBY-532
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: J=C3=B6rg von Frantzius
>            Assignee: Dag H. Wanvik
>              Labels: derby_triage10_11
>         Attachments: deferredConstraints.html, deferredConstraints.html, =
deferredConstraints.html, deferredConstraints.html, derby-532-import-1.diff=
, derby-532-import-1.status, derby-532-import-2.diff, derby-532-syntax-bind=
ing-dict-1.diff, derby-532-syntax-binding-dict-1.status, derby-532-syntax-b=
inding-dict-2.diff, derby-532-syntax-binding-dict-2.status, derby-532-synta=
x-binding-dict-all-1.diff, derby-532-testAlterConstraintInvalidation.diff, =
derby-532-testAlterConstraintInvalidation.status, derby-532-unique-pk-1.dif=
f, derby-532-unique-pk-1.status, derby-532-unique-pk-2.diff, derby-532-xa-1=
.diff, derby-532-xa-2.diff
>
>
> In many situations it is desirable to have constraints checking taking pl=
ace only at transaction commit time, and not before. If e.g. there is a cha=
in of foreign key constraints between tables, insert statements have to be =
ordered to avoid constraint violations. If foreign key references are circu=
lar, the DML has to be split into insert statements and subsequent update s=
tatements by the user.
> In other words, with deferred constraints checking, life is much easier f=
or the user. Also it can create problems with softwares such as object-rela=
tional mapping tools that are not prepared for statement ordering and thus =
depend on deferred constraints checking.


--
This message was sent by Atlassian JIRA
(v6.1#6144)