db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unai Vivi (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-5118) Relational integrity
Date Thu, 10 Mar 2011 10:19:59 GMT

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

Unai Vivi commented on DERBY-5118:

You are right, Rick. I didn't read through the SQL2008 standard because I (mistakenly) assumed
that SQL couldn't have been designed that way for I found that very counter-intuitive. Thank
you for your insightful comment.

> Relational integrity
> --------------------
>                 Key: DERBY-5118
>                 URL: https://issues.apache.org/jira/browse/DERBY-5118
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:
>         Environment: WinXPpro@32bit, Apache Derby EMBEDDED
>            Reporter: Unai Vivi
>            Priority: Minor
>              Labels: keys
> A foreign composite key constraint doesn't match the corresponding primary composite
key unless the order of the columns that make up the composite key is the same.
> E.g.:
> Given a table called "icone" with the following primary key: "CONSTRAINT icone_PK PRIMARY
> "CONSTRAINT BOTTONE_FK3 foreign key(seticone,idazione) references icone on delete cascade"
> and
> "CONSTRAINT BOTTONE_FK3 foreign key(idazione,seticone) references icone on delete cascade"
> should be the same thing (IMHO) but it's not the same according to Derby.
> The latter syntax is apparently broken and when inserting a new row, in the table that
has such constraint, there is an error because Derby swaps the two attributes that make up
the composite key and thus the FK constraint cannot be fulfilled.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message