Derby
  1. Derby
  2. 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.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 10.0.2.0
    • Fix Version/s: None
    • Component/s: SQL
    • Labels:
      None

      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?"

        Issue Links

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          1285d 13h 20m 1 Knut Anders Hatlen 30/Nov/09 15:20
          Resolved Resolved Closed Closed
          417d 2h 28m 1 Kathey Marsden 21/Jan/11 17:48
          Gavin made changes -
          Workflow jira [ 12372391 ] Default workflow, editable Closed status [ 12796853 ]
          Rick Hillegas made changes -
          Link This issue is related to DERBY-6269 [ DERBY-6269 ]
          Kathey Marsden made changes -
          Link This issue relates to DERBY-5249 [ DERBY-5249 ]
          Kathey Marsden made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Knut Anders Hatlen made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Won't Fix [ 2 ]
          Hide
          Knut Anders Hatlen added a comment -

          Setting resolution to "Won't Fix".

          Show
          Knut Anders Hatlen added a comment - Setting resolution to "Won't Fix".
          Knut Anders Hatlen made changes -
          Issue Type Bug [ 1 ] Improvement [ 4 ]
          Hide
          Knut Anders Hatlen added a comment -

          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".

          Show
          Knut Anders Hatlen added a comment - 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".
          Hide
          Daniel John Debrunner added a comment -

          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.

          Show
          Daniel John Debrunner added a comment - 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.
          Andrew McIntyre made changes -
          Fix Version/s 10.2.3.0 [ 12312215 ]
          Hide
          Andrew McIntyre added a comment -

          Unsetting Fix Version for unassigned issues.

          Show
          Andrew McIntyre added a comment - Unsetting Fix Version for unassigned issues.
          Rick Hillegas made changes -
          Fix Version/s 10.2.3.0 [ 12312215 ]
          Fix Version/s 10.2.2.0 [ 12312027 ]
          Hide
          Rick Hillegas added a comment -

          Move to 10.2.3.0.

          Show
          Rick Hillegas added a comment - Move to 10.2.3.0.
          Rick Hillegas made changes -
          Fix Version/s 10.2.1.0 [ 11187 ]
          Fix Version/s 10.2.2.0 [ 12312027 ]
          Hide
          Rick Hillegas added a comment -

          Moving to 10.2.2.0.

          Show
          Rick Hillegas added a comment - Moving to 10.2.2.0.
          Kathey Marsden made changes -
          Fix Version/s 10.2.0.0 [ 11187 ]
          Hide
          Kathey Marsden added a comment -

          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?

          Show
          Kathey Marsden added a comment - 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?
          Mike Matrigali made changes -
          Component/s Store [ 11412 ]
          Hide
          Mike Matrigali added a comment -

          this is an issue with the system catalogs, from discussions on list it looks like not a store issue.

          Show
          Mike Matrigali added a comment - this is an issue with the system catalogs, from discussions on list it looks like not a store issue.
          Satheesh Bandaram made changes -
          Summary Derby is dropping wrong row in SYSCONGLOMERATES when a foreign key(defined on same columns as primary key) is dropped 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.
          Description 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?"
          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?"
          Mamta A. Satoor made changes -
          Field Original Value New Value
          Link This issue relates to DERBY-655 [ DERBY-655 ]
          Mamta A. Satoor created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Mamta A. Satoor
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development