Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 20 Nov 2013 21:26:36 +0000 (UTC)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12313704.1124846280000.3858.1384982796390@arcas>
In-Reply-To: <JIRA.12313704.1124846280000@arcas>
References: <JIRA.12313704.1124846280000@arcas>
Subject: [jira] [Updated] (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:all-tabpanel ]

Dag H. Wanvik updated DERBY-532:
--------------------------------

    Attachment: derby-532-post-scan-3.stat
                derby-532-post-scan-3.diff

Attaching derby-532-post-scan-3, which fixes two bugs: 1. InsertResultSet d=
idn't test on effective deferred status, just initiallyDeferred. Renamed th=
e variables there and in the sort observers accordingly. 2.Changed the orde=
r in which status DEFERRED ALL and the map of individual constraint modes g=
ets propagated to child SQL session contexts (in casu IMPORT_TABLE), so tha=
t individual modes doesn't get clobbered when we set all. This bug was expo=
sed when we started checking on effective deferred status in InsertResultSe=
t. Updated the test to include this case.
Rerunning regressions.


> 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: IndexDescriptor.html, IndexDescriptorImpl.html, Inde=
xRowGenerator.html, deferredConstraints.html, deferredConstraints.html, def=
erredConstraints.html, deferredConstraints.html, derby-532-import-1.diff, d=
erby-532-import-1.status, derby-532-import-2.diff, derby-532-import-3.diff,=
 derby-532-import-3.status, derby-532-more-tests-1.diff, derby-532-more-tes=
ts-1.stat, derby-532-post-scan-1.diff, derby-532-post-scan-1.stat, derby-53=
2-post-scan-2.diff, derby-532-post-scan-2.stat, derby-532-post-scan-3.diff,=
 derby-532-post-scan-3.stat, derby-532-serializable-scan-1.diff, derby-532-=
serializable-scan-2.diff, derby-532-serializable-scan-2.stat, derby-532-syn=
tax-binding-dict-1.diff, derby-532-syntax-binding-dict-1.status, derby-532-=
syntax-binding-dict-2.diff, derby-532-syntax-binding-dict-2.status, derby-5=
32-syntax-binding-dict-all-1.diff, derby-532-testAlterConstraintInvalidatio=
n.diff, derby-532-testAlterConstraintInvalidation.status, derby-532-unique-=
pk-1.diff, derby-532-unique-pk-1.status, derby-532-unique-pk-2.diff, derby-=
532-unique-pk-3.diff, derby-532-unique-pk-3.status, derby-532-xa-1.diff, de=
rby-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)