[
https://issues.apache.org/jira/browse/DERBY-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14064665#comment-14064665
]
Knut Anders Hatlen commented on DERBY-6668:
-------------------------------------------
The patch looks good to me. Judging by the code comments, is sounds as if this
was intentionally allowed, and violations were supposed to be detected later by
AlterTableConstantAction.updateIndex(). Apparently, that doesn't work
correctly. Anyways, disallowing it for now makes sense. We can always enable it
later if we can make it work correctly.
> 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
>
>
> 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)
