db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6668) Truncating a table may silently violate a deferred foreign key.
Date Thu, 17 Jul 2014 12:37:05 GMT

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

Rick Hillegas updated DERBY-6668:
---------------------------------

    Attachment: derby-6668-01-ab-disallowTruncateOnReferencedTable.diff

Thanks for the review, Knut. Attaching derby-6668-01-ab-disallowTruncateOnReferencedTable.diff.
The previous version tripped over two errors in ConstraintCharacteristicsTest: that test was
verifying the edge case where truncating a referenced table does work.

This patch removes the offending test case so that ConstraintCharacteristicsTest passes cleanly
now.

I suspect that some complexity was added to the code to make it support this non-Standard
behavior. We should consider removing that complexity.   

Touches the following additional file:

M       java/testing/org/apache/derbyTesting/functionTests/tests/lang/ConstraintCharacteristicsTest.java


> Truncating a table may silently violate a deferred foreign key.
> ---------------------------------------------------------------
>
>                 Key: DERBY-6668
>                 URL: https://issues.apache.org/jira/browse/DERBY-6668
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.11.0.0
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: derby-6668-01-aa-disallowTruncateOnReferencedTable.diff, derby-6668-01-ab-disallowTruncateOnReferencedTable.diff
>
>
> If you truncate a table which is referenced by a deferred foreign key, orphaned tuples
are left in the foreign table. That is, the foreign key is violated but no exception is raised.
> Since table truncation involves changing conglomerate ids, this may be another case of
derby-6665. Or this may be a new bug.
> The following script shows this behavior:
> {noformat}
> connect 'jdbc:derby:memory:db;create=true';
> create table tunique
> (
>   a int not null unique
> );
> create table tref
> (
>   a int references tunique( a ) initially deferred
> );
> insert into tunique values ( 1 );
> insert into tref values ( 1 );
> truncate table tunique;
> -- the unique table is empty
> select * from tunique;
> -- but the table which references it has a row
> select * from tref;
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message