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] [Updated] (DERBY-532) Support deferrable constraints
Date Wed, 20 Nov 2013 21:26:36 GMT

     [ https://issues.apache.org/jira/browse/DERBY-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dag H. Wanvik updated DERBY-532:
--------------------------------

    Attachment: derby-532-post-scan-3.stat
                derby-532-post-scan-3.diff

Attaching derby-532-post-scan-3, which fixes two bugs: 1. InsertResultSet didn't test on effective
deferred status, just initiallyDeferred. Renamed the variables there and in the sort observers
accordingly. 2.Changed the order in which status DEFERRED ALL and the map of individual constraint
modes gets propagated to child SQL session contexts (in casu IMPORT_TABLE), so that individual
modes doesn't get clobbered when we set all. This bug was exposed when we started checking
on effective deferred status in InsertResultSet. Updated the test to include this case.
Rerunning regressions.






> 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,
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-post-scan-2.diff, derby-532-post-scan-2.stat, derby-532-post-scan-3.diff,
derby-532-post-scan-3.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