[
https://issues.apache.org/jira/browse/DERBY-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983798#comment-13983798
]
Dag H. Wanvik edited comment on DERBY-532 at 5/9/14 8:15 PM:
-------------------------------------------------------------
With the latest commit, deferrable constraints ought to (prove me wrong!) work
for
- unique/primary key constraints
- referential constraints (aka foreign key constraints)
- check constraints
I do not intend to add support for column NOT NULL constraints. Also, there is
no support yet for changing constraints to "not enforced", otherwise the
standard semantics of SQL 2011 should apply.
I intend to add a few more tests for foreign key constraints. [Update: Cf
DERBY-6559].
was (Author: dagw):
With the latest commit, deferrable constraints ought to (prove me wrong!) work
for
- unique/primary key constraints
- referential constraints (aka foreign key constraints)
- check constraints
I do not intend to add support for column NOT NULL constraints. Also, there is
no support yet for changing constraints to "not enforced", otherwise the
standard semantics of SQL 2011 should apply.
I intend to add a few more tests for foreign key constraints.
> 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
> Fix For: 10.11.0.0
>
> Attachments: IndexDescriptor.html, IndexDescriptorImpl.html,
> IndexRowGenerator.html, SortObserver.html, deferredConstraints.html,
> deferredConstraints.html, deferredConstraints.html, deferredConstraints.html,
> deferredConstraints.html, deferredConstraints.html,
> derby-532-allow-pk-unique-1.diff, derby-532-allow-pk-unique-1.status,
> derby-532-check-constraints-1.diff, derby-532-check-constraints-1.stat,
> derby-532-check-constraints-2.diff, derby-532-check-constraints-2.stat,
> 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-fk-1.diff, derby-532-fk-3.diff, derby-532-fk-3.stat,
> derby-532-fk-4.diff, derby-532-fk-5.diff, derby-532-fk-5.stat,
> derby-532-fk-6.diff, derby-532-fk-6.stat, derby-532-fk-7.diff,
> derby-532-fk-7.stat, derby-532-fk-baseline-2.diff,
> derby-532-fk-baseline.diff, 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-metadata-queries.diff,
> derby-532-metadata-queries.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-upgrade-1.diff, derby-532-upgrade-1.status,
> derby-532-upgrade-1b.diff, 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.2#6252)
