db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-532) Support deferrable constraints
Date Tue, 19 Nov 2013 20:17:22 GMT

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

Mike Matrigali commented on DERBY-532:

first half of review, really only questions and requests for more comments, code so far looks
fine.   It would be 
good to get someone with more language expertise to look at that part.   I can probably do
a good job reviewing
the changes that are there - but someone else might need to review to think about the changes
that aren't there
that might be needed.   I am ok with leaving the sort observer stuff.

Index: java/engine/org/apache/derby/catalog/IndexDescriptor.java
nit: maybe would be good to add comments here describing that unique
     deferrable indexes are implemented using store non-uniqe indexes, and
     that sql layer owns enforcing uniqueness.

Index: java/engine/org/apache/derby/catalog/types/IndexDescriptorImpl.java
nit: same comment as about about more detail about deferrable indexes.

some document table describing the use of the following associating it with
deferred and non-deffered and different contraint types might help to make
it clearer:

boolean isUnique,
boolean isUniqueWithDuplicateNulls,
boolean isUniqueDeferrable,
boolean hasDeferrableChecking,

Index: java/engine/org/apache/derby/iapi/sql/conn/LanguageConnectionContext.java

no comment.

Index: java/engine/org/apache/derby/iapi/sql/conn/SQLSessionContext.java
no comment.

Index: java/engine/org/apache/derby/iapi/sql/conn/StatementContext.java
no comment.

nit: same comment about expanding on what isUniqueDeferrable means for the index

would be nice for the 3 new interfaces to have javadoc comments for each,
explaing their use in more detail.

Index: java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java
nice you got rid of old version check here.

Index: java/engine/org/apache/derby/impl/sql/execute/AlterConstraintConstantActi
o would be good to have tests that alter back and forth from deferred and
  not deffered and make sure subsequent actions do the right thing.  Could
  looks like existing mechanism should work, but seems a good code path to

Index: java/engine/org/apache/derby/impl/sql/execute/CreateIndexConstantAction.j
some comment on why sharing is turned off for deferable constraints would
be good.  A user is going to complain at some point when they see duplicate
indexes taking up twice space that they don't think they need.

Index: java/engine/org/apache/derby/impl/sql/execute/DeferredDuplicates.java

  caught and remapped can someone comment on if this is the standard. Is it
  ok that this type of constrain will throw a different error than previous
  constraints?  I think it is ok with standard as they all start with

  can you comment on statement vs transaction level rollback.  While thinking
  about this I have always assumed transaction level rollback to get the
  rows out of the table.  I think statement level must be when savepoints
  are involved.

> 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

View raw message