db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [Derby-655] : getImportedKeys returns duplicate rows in some cases
Date Thu, 25 May 2006 16:40:14 GMT
Mamta Satoor wrote:

> But for the existing duplicate foreign keys in the database, there will
> still be duplicate conglomerateids in SYSCONGLOMERATES and that will make
> getImportedKeys return incorrect number of rows. We can solve this in
> upcoming Derby10.2 release by adding a system generated primary key to
> SYSCONGLOMERATES (as suggested by Stan). This will make sure that existing
> duplicate rows with same conglomerateid can be uniquely identified using
> system generated primary key. getImportedKeys will need to be fixed as
> shwon
> by Stan's example query. This can only be done for Derby10.2. But for older
> Derby releases, I don't think we can add a new column to a system table for
> compatibility reasons and hence older releases will continue to return
> incorrect number of rows from getImportedKeys for existing duplicate
> foreign
> key indexes.
> 
> Someone should correct if I am missing something here.

I don't think we should be creating a new column in the table for this.
Seems like it would be possible to fix up the data in the table so that
the data is unique in the conglomerateid column. I can think of two ways
to do this:

1) Have upgrade code that patches the system tables

2) Have upgrade code that drops & re-creates indexes/constraints that
have this problem.

Seems like the issue with dropping the wrong row on a drop constraint
(DERBY-1343) could be fixed with additional qualifications on the row
search, ie. require the isconstraint column to be true.

Dan.



Mime
View raw message