Derby is dropping wrong row in SYSCONGLOMERATES when a foreign key(defined on
same columns as primary key) is dropped
----------------------------------------------------------------------------------------------------------------------
Key: DERBY-1343
URL: http://issues.apache.org/jira/browse/DERBY-1343
Project: Derby
Type: Bug
Components: SQL, Store
Versions: 10.0.2.0
Reporter: Mamta A. Satoor
When a user defines a constraint, Derby checks to see if it's backing index is
a duplicate of an existing index and if yes, then it shares the same
conglomerates for both such indexes. Code for this is in
org.apache.derby.impl.sql.execute.CreateIndexConstantAction.executeConstantAction.
This causes Derby to have duplicate rows in sysconglomerates with same
conglomerateid. (More information on this can be found in thread
http://www.nabble.com/-Derby-655-+%3A+getImportedKeys+returns+duplicate+rows+in+some+cases-t1673189.html#a4535887
titled "[DERBY-655] : getImportedKeys returns duplicate rows in some cases".
During drop constraint, it looks like Derby is not able to identify the correct
row in SYSCONGLOMERATES, if there are duplicate rows with same conglomerateid
and as a consequence, wrong row gets dropped in SYSCONGLOMERATES. More
information with an example on this can be found in thread
http://www.nabble.com/When+foreign+key+is+dropped%2C+is+Derby+dropping+the+wrong+row+from+SYS.SYSCONGLOMERATES--t1654121.html#a4481463
titled "When foreign key is dropped, is Derby dropping the wrong row from
SYS.SYSCONGLOMERATES?"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
