db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-532) Support deferrable constraints
Date Wed, 11 Dec 2013 14:35:09 GMT

    [ https://issues.apache.org/jira/browse/DERBY-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13845435#comment-13845435

ASF subversion and git services commented on DERBY-532:

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

DERBY-532 Support deferrable constraints

Patch derby-532-nullableUniqueFix. When we changed the implementation from
special treatment of deferrable constraints in the BTree, a couple of extra
predicates needed to be added were omitted - added those here: we should not
mark the physical index with "uniqueWithDuplicateNulls" if it is deferrable.
This error was found when running the regressions with default deferrable for
all pk and unique constraints.

We also removed an unused flag "hasDeferrableChecking" in the same places (it is
not longer used by the physical index).

Added a new test case, testCompressTable, which tests the
"uniqueWithDuplicateNulls" case.

We also change the behavior in the following way for deferrable, but not
deferred constraints: if we hit a time-out or dead-lock when checking uniqueness
(in the BTree scan), we throw that time-out or dead-lock. Up till now we
converted it to a duplicate exception. We will only assume it can be a duplicate
- for later checking - iff the constraint mode is deferrable.

> Support deferrable constraints
> ------------------------------
>                 Key: DERBY-532
>                 URL: https://issues.apache.org/jira/browse/DERBY-532
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Jörg von Frantzius
>            Assignee: Dag H. Wanvik
>              Labels: derby_triage10_11
>         Attachments: IndexDescriptor.html, IndexDescriptorImpl.html, IndexRowGenerator.html,
SortObserver.html, deferredConstraints.html, deferredConstraints.html, deferredConstraints.html,
deferredConstraints.html, deferredConstraints.html, derby-532-fix-drop-not-nullable.diff,
derby-532-fix-drop-not-nullable.status, derby-532-fix-metadata-1.diff, derby-532-fix-metadata-1.status,
derby-532-import-1.diff, derby-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-tests-1.stat, derby-532-nullableUniqueFix.diff,
derby-532-nullableUniqueFix.status, derby-532-post-scan-1.diff, derby-532-post-scan-1.stat,
derby-532-post-scan-2.diff, derby-532-post-scan-2.stat, derby-532-post-scan-3.diff, derby-532-post-scan-3.stat,
derby-532-post-scan-4.diff, derby-532-post-scan-4.stat, derby-532-serializable-scan-1.diff,
derby-532-serializable-scan-2.diff, derby-532-serializable-scan-2.stat, derby-532-syntax-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-532-syntax-binding-dict-all-1.diff, derby-532-test-speedup.diff, derby-532-test-speedup.status,
derby-532-test-with-default-deferrable-all-over.diff, derby-532-testAlterConstraintInvalidation.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,
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 place only at
transaction commit time, and not before. If e.g. there is a chain of foreign key constraints
between tables, insert statements have to be ordered to avoid constraint violations. If foreign
key references are circular, the DML has to be split into insert statements and subsequent
update statements by the user.
> In other words, with deferred constraints checking, life is much easier for the user.
Also it can create problems with softwares such as object-relational mapping tools that are
not prepared for statement ordering and thus depend on deferred constraints checking.

This message was sent by Atlassian JIRA

View raw message