Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 30 Aug 2013 18:24:52 +0000 (UTC)
From: "ASF subversion and git services (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12313704.1124846280000.61726.1377887092234@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=3D13754=
978#comment-13754978 ]=20

ASF subversion and git services commented on DERBY-532:
-------------------------------------------------------

Commit 1519045 from [~dagw] in branch 'code/trunk'
[ https://svn.apache.org/r1519045 ]

DERBY-532: Support deferrable constraints

Patch derby-532-testAlterConstraintInvalidation.

Adds a fixture to test that prepared statement is invalidated when a
table its depends on undergoes an ALTER TABLE ALTER CONSTRAINT
statement. As it turns out, this is already handled by the common
machinery for ALTER TABLE.
               =20
> 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, =
derby-532-syntax-binding-dict-1.diff, derby-532-syntax-binding-dict-1.statu=
s, derby-532-syntax-binding-dict-2.diff, derby-532-syntax-binding-dict-2.st=
atus, derby-532-syntax-binding-dict-all-1.diff, derby-532-testAlterConstrai=
ntInvalidation.diff, derby-532-testAlterConstraintInvalidation.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira