[
https://issues.apache.org/jira/browse/DERBY-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14065056#comment-14065056
]
Knut Anders Hatlen edited comment on DERBY-6665 at 7/17/14 4:07 PM:
--------------------------------------------------------------------
Fixing this was a little more involved than I had hoped, and I am going to be
out next week, so I'm unassigning myself from this bug so that I don't block
others from picking it up.
The attached patch [^braindump.diff] shows what I've tried so far.
ForeignKeysDeferrableTest passes with that patch, including the test case for
this bug.
I don't quite trust the logic I've put into IndexChanger and InsertResultSet to
map back from the index conglomerate number to the constraint id (remember that
it's a one to many relation between conglomerate numbers and constraints).
Also, I still haven't eliminated all uses of
SQLSessionContextImpl.uniquePKConstraintModes, which still hashes on a Long
instead of a UUID. And I haven't eliminated all callers of
LanguageConnectionContext.isEffectivelyDeferred(SQLSessionContext sc, long
indexCID). Both of those have parallel implementations that use UUID instead of
long. I'd expect that all users of the data structures and methods that use a
long are either buggy or redundant.
was (Author: knutanders):
Fixing this was a little more involved than I had hoped, and I am going to be
out next week, so I'm unassigning myself from this bug so that I don't block
others from picking it up.
The attached patch [^braindump.diff] shows what I've tried so far.
ForeignKeysDeferrableTest passes with that patch, including the test case for
this bug.
I don't quite trust the logic I've put into IndexChanger and InsertResultSet to
map back from the index conglomerate number to the constraint id (remember that
it's a one to many relation between conglomerate numbers and constraints).
Also, I still haven't eliminated all uses of
SQLSessionContextImpl.uniquePKConstraintModes, which still hashes on a Long
instead of a UUID. And I haven't eliminated all callers of
LanguageConnectionContext.isEffectivelyDeferred(SQLSessionContext sc, long
indexCID). Both of those have parallel implementations that use UUID instead of
long. I'd expect that all users of these data structures and methods are either
buggy or redundant.
> Violation of deferred constraints not detected when conglomerates are shared
> ----------------------------------------------------------------------------
>
> Key: DERBY-6665
> URL: https://issues.apache.org/jira/browse/DERBY-6665
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.11.0.0
> Reporter: Knut Anders Hatlen
> Attachments: braindump.diff, junit.diff
>
>
> See the following script:
> {noformat}
> ij version 10.11
> ij> connect 'jdbc:derby:memory:db;create=true';
> ij> create table t1(x int primary key);
> 0 rows inserted/updated/deleted
> ij> create table t2(x int primary key);
> 0 rows inserted/updated/deleted
> ij> create table t3(x int, constraint fk1 foreign key (x) references t1
> initially deferred, constraint fk2 foreign key (x) references t2 initially
> deferred);
> 0 rows inserted/updated/deleted
> ij> insert into t1 values 1;
> 1 row inserted/updated/deleted
> ij> autocommit off;
> ij> insert into t3 values 1;
> 1 row inserted/updated/deleted
> ij> insert into t2 values 1;
> 1 row inserted/updated/deleted
> ij> delete from t1;
> 1 row inserted/updated/deleted
> ij> commit;
> ij> select * from t1;
> X
> -----------
> 0 rows selected
> ij> select * from t2;
> X
> -----------
> 1
> 1 row selected
> ij> select * from t3;
> X
> -----------
> 1
> 1 row selected
> {noformat}
> Since T3.X contains a value (1) that is not present in T1, the foreign key
> FK1 is violated, and the COMMIT statement should have failed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
