db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1343) It is possible to have duplicate entries in conglomerateId of sysconglomerates before DERBY-655 was fixed in 10.0 or 10.1 databases. It is desirable to patch these databases on upgrade to 10.2 so conglomerateId becomes unique again.
Date Tue, 13 Mar 2007 23:52:09 GMT

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

Daniel John Debrunner commented on DERBY-1343:
----------------------------------------------

I stumbled across this bug as part of the cleanup for DERBY-2397, since the code in DropConstraintConstantAction
(copied here) just looked wrong.

				for (int i = 0; i < conglomDescs.length; i++)
				{
					if (conglomDescs[i].isConstraint())
					{
						DropIndexConstantAction.dropIndex(dm, dd, tc,
													conglomDescs[i], td, 
													lcc);
						break;
					}
				}

The code looks wrong because of the 'break", why is the first match good enough? As Mamta
pointed out in the thread above the "wrong" CoglomerateDescriptor (row in SYSCONGLOMERATES)
gets dropped.

Looking at it more though I don't think it matters, both ConglomerateDescriptors (rows) have
the same key information and so it actually doesn't matter which gets dropped. The only difference
is the conglomerate name for the backing index which is never used. As far as I can see the
ConstraintDescriptor only links to the ConglomerateDescriptor through the UUID (which is the
same in the two rows in the 10.0 code before the fix to DERBY-655).

So I don't see any real need to write upgrade code that handles this situation. I will add
some comments to the code to clarify it.

> It is possible to have duplicate entries in conglomerateId of sysconglomerates before
DERBY-655 was fixed in 10.0 or 10.1 databases. It is desirable to patch these databases on
upgrade to 10.2 so conglomerateId becomes unique again.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1343
>                 URL: https://issues.apache.org/jira/browse/DERBY-1343
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.0.2.0
>            Reporter: Mamta A. Satoor
>
> Because of an optimization implemented in before Derby 10.0 release, it is possible to
have duplicate entries in conglomerateId column. It would be good to patch these entries during
upgrade to 10.2 or later so that conglomerateIds become unique again. See the discussion and
proposed solutions at:
> http://www.nabble.com/-Derby-655-+%3A+getImportedKeys+returns+duplicate+rows+in+some+cases-t1673189.html#a4535887
> 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.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message