[
https://issues.apache.org/jira/browse/DERBY-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248558#comment-16248558
]
Rick Hillegas commented on DERBY-6977:
--------------------------------------
Thanks for the feedback, Bryan and Trejkaz. To answer Bryan's questions:
BP> I guess that, once we generate the sequence name, it is just a string?
Right. It is stored as a string and is a valid delimited identifier. One
advantage of the scheme being retired is that the index name was
case-insensitive and could be used in metadata queries without being
double-quoted. That seemed like a small advantage at the cost of complicated
and (apparently) buggy code.
BP> So, if we change the name generator, we have no upgrade issues?
I will run the upgrade tests, upgrading from all official releases back until
Derby was open-sourced. I will ponder whether there are any upgrade issues.
Right now, I am correcting several tests which expected the old style of index
names. So far, I have not uncovered any clues about the motivation for the old
style. It goes back to the initial open-sourcing of Derby.
> Autogenerated index name occasionally generates a name which already exists
> ---------------------------------------------------------------------------
>
> Key: DERBY-6977
> URL: https://issues.apache.org/jira/browse/DERBY-6977
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.13.1.1
> Reporter: Trejkaz
> Attachments: derby-6977-01-aa-useUUID.diff
>
>
> This has been happening for as long as I can remember, but v10.13.1.1 is the
> version we're currently at and I still see builds fail at random due to this.
> In a migration, we execute this statement:
> {noformat}
> CREATE TABLE GuidMappingCache (
> guidhigh BIGINT NOT NULL,
> guidlow BIGINT NOT NULL,
> luceneid INTEGER NOT NULL,
> PRIMARY KEY (guidhigh, guidlow)
> )
> {noformat}
> This randomly fails with the following sort of error:
> {noformat}
> Caused by: java.sql.SQLException: Index 'SQL171110050418720' already exists
> in Schema 'APP'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at OurCode.execute(...)
> Caused by: ERROR X0Y32: Index 'SQL171110050418720' already exists in Schema
> 'APP'.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.duplicateDescriptorException(Unknown
> Source)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.CreateIndexConstantAction.executeConstantAction(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.CreateConstraintConstantAction.executeConstantAction(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> ... 37 more
> {noformat}
> The last time someone was looking into this, it was somehow very reproducible
> for them but not for anyone else. I'm now seeing it occasionally on tests on
> our build farm. As usual, no matter how many times I run the test here, I
> can't get the same failure to occur.
> How is this value being generated?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
