db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DERBY-532) Support deferrable constraints
Date Thu, 28 Nov 2013 15:19:40 GMT

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

Dag H. Wanvik edited comment on DERBY-532 at 11/28/13 3:18 PM:
---------------------------------------------------------------

Here is one fallout of running the regressions with default constraint mode deferrable.

Uploading a patch ("derby-532-fix-metadata-1") that fixes broken database metadata for deferred
constraint indexes: the metadata query used the method IndexDescriptor#isUnique to determine
logical uniqueness, but it really represents physical uniqueness now. For deferred unique
constraints, the method that should be used is "isUniqueDeferrable". Added a test, and also
added client/server run of the regression test for deferred constraints. 

Before the fix, the added test fixture "testDatabaseMetaData" failed in that the index in
question was identified as non unique, but it is logically unique.

When changing the code for the database metadata query, I discovered DERBY-6423.


was (Author: dagw):
Here is one fallout of running the regressions with default constraint mode deferrable.

Uploading a patch that fixes broken database metadata for deferred constraint indexes: the
metadata query used the method IndexDescriptor#isUnique to determine logical uniqueness, but
it really represents physical uniqueness now. For deferred unique constraints, the method
that should be used is "isUniqueDeferrable". Added a test, and also added client/server run
of the regression test for deferred constraints. 

Before the fix, the added test fixture "testDatabaseMetaData" failed in that the index in
question was identified as non unique, but it is logically unique.


> 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-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-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-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
(v6.1#6144)

Mime
View raw message