db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6587) Foreign Key constraint not matched when using UUID in a composite foreign key
Date Thu, 05 Jun 2014 18:33:01 GMT

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

Myrna van Lunteren commented on DERBY-6587:
-------------------------------------------

I confirmed that with Pascal's patch, the problem goes away.
I also checked that no other result of compare is evaluated - within the same method - like
this.
There are a number of places in the code where the result from a compare is returned to a
calling method; I'll check that those results are handled correctly next.

> Foreign Key constraint not matched when using UUID in a composite foreign key
> -----------------------------------------------------------------------------
>
>                 Key: DERBY-6587
>                 URL: https://issues.apache.org/jira/browse/DERBY-6587
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.10.2.0
>         Environment: Windows 7, Java 7
>            Reporter: Pascal GrĂ¼n
>            Assignee: Dag H. Wanvik
>         Attachments: DERBY-6587_tst.diff, RIBulkChecker.diff, TABLE1_T.csv, TABLE2_T.csv,
schema.sql
>
>
> There is a problem in org.apache.derby.impl.sql.execute.RIBulkChecker:
> result = fkCol.compare(refCol);
>             if (result == 1)
>             {
>                 return GREATER_THAN;
>             }
>             else if (result == -1)
>             {
>                 return LESS_THAN;
>             }
> where the JavaDoc for "compare" explicitly states that one must not use 1 or -1 to check
the return value.
> The problem can be reproduced when creating a table with two fields, "UUID_FIELD char
(16) for bit data" and "NUM_FIELD integer", then having a foreign key to these two fields
and then using the bulk import, i.e. "CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE ..."



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

Mime
View raw message