[
https://issues.apache.org/jira/browse/DERBY-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13965726#comment-13965726
]
Dag H. Wanvik commented on DERBY-532:
-------------------------------------
The approach take for deferring foreign keys is similar to that taken for the
other constraints: when we detect a violation when inserting or updating the
referring table, and when detecting a violation when deleting or updating the
referenced table (only when we have ON DELETE (or UPDATE) NO ACTION), we save
the key in a temporary table instead of throwing an exception. At check time,
typically on commit, we revisit first the supporting index of referencing table
to see if there might still be a problem. If that key is (still) present, we
must also check the corresponding index in the referenced table. If that is
found, all is good. Otherwise we throw. The main new pieces of the machinery
are ForeignKeysDeferrableTest#rememberFKViolation and #validateForeignKey and
GenericLanguageConnectionContext#doValidateForeignKey and its uses.
> 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, 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-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-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)
