[jira] Updated: (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 databas
[ https://issues.apache.org/jira/browse/DERBY-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1343: -- Issue Type: Improvement (was: Bug) >From the comments, this sounds more like an improvement than a bug, so I'm >reclassifying the issue. However, I don't think it's very likely anymore that someone will pick up this issue, given that it only affects upgrade from 10.0 and 10.1. I propose that we close this issue as "Won't Fix". > 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: Improvement > 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.
[jira] Updated: (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 databas
[ http://issues.apache.org/jira/browse/DERBY-1343?page=all ] Rick Hillegas updated DERBY-1343: - Fix Version/s: 10.2.3.0 (was: 10.2.2.0) Move to 10.2.3.0. > 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: http://issues.apache.org/jira/browse/DERBY-1343 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.0.2.0 >Reporter: Mamta A. Satoor > Fix For: 10.2.3.0 > > > 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. - 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
[jira] Updated: (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 databas
[ http://issues.apache.org/jira/browse/DERBY-1343?page=all ] Rick Hillegas updated DERBY-1343: - Fix Version/s: 10.2.2.0 (was: 10.2.1.0) Moving to 10.2.2.0. > 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: http://issues.apache.org/jira/browse/DERBY-1343 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.0.2.0 >Reporter: Mamta A. Satoor > Fix For: 10.2.2.0 > > > 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. - 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
[jira] Updated: (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 databas
[ http://issues.apache.org/jira/browse/DERBY-1343?page=all ] Kathey Marsden updated DERBY-1343: -- Fix Version/s: 10.2.0.0 I am a litle confused by this JIRA. Is it an upgrade requirement for 10.2, e.g. should this be marked URGENT or is it just a nice to have? What are the ramifications of not fixing it? How would users be affected? > 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: http://issues.apache.org/jira/browse/DERBY-1343 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.0.2.0 >Reporter: Mamta A. Satoor > Fix For: 10.2.0.0 > > > 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. - 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
[jira] Updated: (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 databas
[ http://issues.apache.org/jira/browse/DERBY-1343?page=all ] Mike Matrigali updated DERBY-1343: -- Component: (was: Store) this is an issue with the system catalogs, from discussions on list it looks like not a store issue. > 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: http://issues.apache.org/jira/browse/DERBY-1343 > Project: Derby > Type: Bug > Components: SQL > 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. - 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
[jira] Updated: (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 databas
[ http://issues.apache.org/jira/browse/DERBY-1343?page=all ] Satheesh Bandaram updated DERBY-1343: - Summary: 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. (was: Derby is dropping wrong row in SYSCONGLOMERATES when a foreign key(defined on same columns as primary key) is dropped) Description: 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?" was: 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?" > 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: http://issues.apache.org/jira/browse/DERBY-1343 > Project: Derby > Type: Bug > Components: SQL, Store > 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 r
