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] [Commented] (DERBY-6665) Violation of deferred constraints not detected when conglomerates are shared
Date Tue, 22 Jul 2014 18:18:39 GMT

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

Rick Hillegas commented on DERBY-6665:
--------------------------------------

There were lots of errors in the tests, but they appear to all be in ConstraintCharacteristicsTest.
The root cause seems to be the following code in DeferredConstraintsMemory, which is trying
to use the tablets conglomerate number in order to look up the buckets of candidate check
constraint violations:

{noformat}
    public static Enumeration<Object> getDeferredCheckConstraintLocations(
            Activation activation,
            long validatingBaseTableCID) throws StandardException {

        CheckInfo ci = (DeferredConstraintsMemory.CheckInfo)activation.
                getLanguageConnectionContext().
                getDeferredHashTables().get(
                    Long.valueOf(validatingBaseTableCID));
        return ci.infoRows.elements();
    }
{noformat}

The fix is probably to use some other handle to look up those buckets. I will need to study
the patch to figure out whether that other handle is the table UUID or something else.

> 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, derby-6665-01-aa-remove-uniquePKConstraintModes.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)

Mime
View raw message