Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 12 Nov 2013 23:17:17 +0000 (UTC)
From: "Mike Matrigali (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12313704.1124846280000.61045.1384298237916@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=3D13820=
630#comment-13820630 ]=20

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

could you describe what behavior you expect from the current algorithm in t=
he following case:
deferable constraint, in deferred mode
xact 1:
inserts v
does not commit
xact 2:
inserts duplicate v

reading above it seems like xact 2 is going to block doing the "ahead" chec=
k, which does not seem
to be what a deferred constraint wants to happen.

> 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-import-3.di=
ff, derby-532-import-3.status, derby-532-more-tests-1.diff, derby-532-more-=
tests-1.stat, derby-532-serializable-scan-1.diff, derby-532-syntax-binding-=
dict-1.diff, derby-532-syntax-binding-dict-1.status, derby-532-syntax-bindi=
ng-dict-2.diff, derby-532-syntax-binding-dict-2.status, derby-532-syntax-bi=
nding-dict-all-1.diff, derby-532-testAlterConstraintInvalidation.diff, derb=
y-532-testAlterConstraintInvalidation.status, derby-532-unique-pk-1.diff, d=
erby-532-unique-pk-1.status, derby-532-unique-pk-2.diff, derby-532-unique-p=
k-3.diff, derby-532-unique-pk-3.status, derby-532-xa-1.diff, derby-532-xa-2=
.diff, derby-532-xa-3.diff, derby-532-xa-3.status
>
>
> 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)