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 Tue, 19 Nov 2013 14:59:24 GMT

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

Dag H. Wanvik edited comment on DERBY-532 at 11/19/13 2:57 PM:
---------------------------------------------------------------

Attaching derby-532-post-scan-1 which changes the serializable scan to check before the insert
to use an unconditional insert (in IndexChanger#insertAndCheckDups) plus a post-insert scan
to check for duplicates. This scan presently uses a scan that will wait if a row is locked.

A time.out on insert will presume it's a duplicate and schedule a commit-time check.
This will changed when we implement the optimization described in DERBY-6419. A time-out (or
dead-lock) at commit-time will be reported as such. A change of constraint mode to immediate
which can't get a lock will also report a time-out or dead-lock.

Re-running regressions.


was (Author: dagw):
Attaching derby-532-post-scan-1 which changes the serializable scan to check before the insert
to use an unconditional insert (in IndexChanger#insertAndCheckDups) plus a post-insert scan
to check for duplicates. This scan presently uses a scan that will wait if a row is locked.

A time.out on insert will presume it's a duplicate and schedule a commit-time check.
This will changed when we implement the optimization described in DERBY-6419. A time-out (or
dead-lock) at commit-time will be reported as such. A change of constraint mode to immediate
which can't get a lock will also report a time-out or dead-lock.

> 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: deferredConstraints.html, deferredConstraints.html, deferredConstraints.html,
deferredConstraints.html, 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-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-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