Derby
  1. Derby
  2. DERBY-4946

Derby 10.7 DatabaseMetaData.getTypeInfo() should not return BOOLEAN for a soft upgraded database

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.7.1.1, 10.8.1.2
    • Fix Version/s: 10.7.1.4, 10.8.1.2
    • Component/s: JDBC
    • Labels:
      None
    • Issue & fix info:
      High Value Fix, Repro attached
    • Bug behavior facts:
      Regression

      Description

      Derby 10.7 DatabaseMetaData.getTypeInfo() should not return the BOOLEAN data type with a soft upgraded database as often applications use getTypeInfo() to determine if tables can be created with this type.

      To reproduce and see the impact of the problem, first create the database testdb with 10.6
      ij version 10.6
      ij> connect 'jdbc:derby:testdb;create=true';
      ij>

      run the attached program UseDBMetaForBool with 10.6 and it runs fine.
      $ java UseDBMetaForBool
      getDriverVersion10.6.2.3 - (1026030M)
      supportsBoolean = false Make my table accordingly
      CREATING SMALLINT TABLE SINCE NO BOOLEAN
      getBoolean=true
      getString=1

      Next run the program against 10.7 in soft upgrade mode and it fails with:
      $ java UseDBMetaForBool
      getDriverVersion10.7.1.2 - (1040699M)
      supportsBoolean = true Make my table accordingly
      CREATING BOOLEAN TABLE
      Exception in thread "main" java.sql.SQLException: Use of 'BOOLEAN' requires data
      base to be upgraded from version 10.6 to version 10.7 or later.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLE
      xceptionFactory40.java:95)
      at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:256)

      at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException
      (TransactionResourceImpl.java:396)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Tr
      ansactionResourceImpl.java:348)
      at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConne
      ction.java:2284)
      at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Connection
      Child.java:82)
      at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java
      :616)
      at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatemen
      t.java:176)
      at UseDBMetaForBool.main(UseDBMetaForBool.java:28)
      Caused by: java.sql.SQLException: Use of 'BOOLEAN' requires database to be upgra
      ded from version 10.6 to version 10.7 or later.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExc
      eptionFactory.java:45)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransport
      AcrossDRDA(SQLExceptionFactory40.java:119)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLE
      xceptionFactory40.java:70)
      ... 8 more
      Caused by: ERROR XCL47: Use of 'BOOLEAN' requires database to be upgraded from v
      ersion 10.6 to version 10.7 or later.
      at org.apache.derby.iapi.error.StandardException.newException(StandardEx
      ception.java:343)
      at org.apache.derby.impl.sql.catalog.DD_Version.checkVersion(DD_Version.
      java:845)
      at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.checkVersion(Dat
      aDictionaryImpl.java:9662)
      at org.apache.derby.impl.sql.compile.SQLParser.checkVersion(SQLParser.ja
      va:327)
      at org.apache.derby.impl.sql.compile.SQLParser.dataTypeCommon(SQLParser.
      java:3336)
      at org.apache.derby.impl.sql.compile.SQLParser.dataTypeDDL(SQLParser.jav
      a:3260)
      at org.apache.derby.impl.sql.compile.SQLParser.columnDefinition(SQLParse
      r.java:3125)
      at org.apache.derby.impl.sql.compile.SQLParser.tableElement(SQLParser.ja
      va:3090)
      at org.apache.derby.impl.sql.compile.SQLParser.tableElementList(SQLParse
      r.java:3061)
      at org.apache.derby.impl.sql.compile.SQLParser.tableDefinition(SQLParser
      .java:10204)
      at org.apache.derby.impl.sql.compile.SQLParser.createStatements(SQLParse
      r.java:2079)
      at org.apache.derby.impl.sql.compile.SQLParser.StatementPart(SQLParser.j
      ava:1974)
      at org.apache.derby.impl.sql.compile.SQLParser.Statement(SQLParser.java:
      1892)
      at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(ParserImp
      l.java:151)
      at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatemen
      t.java:282)
      at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.j
      ava:90)
      at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepa
      reInternalStatement(GenericLanguageConnectionContext.java:1101)
      at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java
      :607)
      ... 2 more

      Finally, hard upgrade and see it runs again once the upgrade has been performed:
      $ java org.apache.derby.tools.ij
      ij version 10.7
      ij> connect 'jdbc:derby:testdb;upgrade=true';
      ij>

      kmarsden@IBM-93AE43E63C0 ~/repro/softUpgr
      $ java UseDBMetaForBool
      getDriverVersion10.7.1.2 - (1040699M)
      supportsBoolean = true Make my table accordingly
      CREATING BOOLEAN TABLE
      getBoolean=true
      getString=true

      The application should run in soft upgrade mode and DatabaseMetaData.getTypeInfo() should not return the BOOLEAN type in soft upgrade before it is available to use.

      1. UseDBMetaForBool.java
        1 kB
        Kathey Marsden
      2. odbc+tests.diff
        8 kB
        Knut Anders Hatlen
      3. bool.diff
        2 kB
        Knut Anders Hatlen

        Activity

        Kathey Marsden created issue -
        Hide
        Kathey Marsden added a comment -

        Attaching reproduction for soft upgrade issue with DatabaseMetaData.getTypeInfo() see description for instructions.

        Show
        Kathey Marsden added a comment - Attaching reproduction for soft upgrade issue with DatabaseMetaData.getTypeInfo() see description for instructions.
        Kathey Marsden made changes -
        Field Original Value New Value
        Attachment UseDBMetaForBool.java [ 12466360 ]
        Hide
        Rick Hillegas added a comment -

        Prior to 10.7, the behavior of Derby's BOOLEAN datatype was, frankly, broken. It was a half datatype. You could not create columns of BOOLEAN type but you could select columns of BOOLEAN type (from the system tables). From the point of view of applications wanting to know what kind of data they could INSERT, it was correct for DatabaseMetaData.getTypeInfo() to omit the BOOLEAN datatype. However, from the point of view of applications wanting to know what kind of datatypes they could SELECT, it was wrong for DatabaseMetaData.getTypeInfo() to omit the BOOLEAN datatype. The full, gory state of the mess is described in the appendixes of the functional spec attached to DERBY-499.

        In short, prior to 10.7, including or omitting BOOLEAN from DatabaseMetaData.getTypeInfo() would have been correct or incorrect depending on what your application's needs were. I have no enthusiasm for changing this output from one wrong answer to another. Conversely, I won't veto your work if you want to change which wrong answer we give.

        Users will not get the right answer until they hard-upgrade to 10.7, the release which fixes this datatype.

        Show
        Rick Hillegas added a comment - Prior to 10.7, the behavior of Derby's BOOLEAN datatype was, frankly, broken. It was a half datatype. You could not create columns of BOOLEAN type but you could select columns of BOOLEAN type (from the system tables). From the point of view of applications wanting to know what kind of data they could INSERT, it was correct for DatabaseMetaData.getTypeInfo() to omit the BOOLEAN datatype. However, from the point of view of applications wanting to know what kind of datatypes they could SELECT, it was wrong for DatabaseMetaData.getTypeInfo() to omit the BOOLEAN datatype. The full, gory state of the mess is described in the appendixes of the functional spec attached to DERBY-499 . In short, prior to 10.7, including or omitting BOOLEAN from DatabaseMetaData.getTypeInfo() would have been correct or incorrect depending on what your application's needs were. I have no enthusiasm for changing this output from one wrong answer to another. Conversely, I won't veto your work if you want to change which wrong answer we give. Users will not get the right answer until they hard-upgrade to 10.7, the release which fixes this datatype.
        Hide
        Kathey Marsden added a comment -

        Thanks Rick for your insight. I want to understand your statement.

        "However, from the point of view of applications wanting to know what kind of datatypes they could SELECT, it was wrong for DatabaseMetaData.getTypeInfo() to omit the BOOLEAN datatype. "

        I was trying to think under what circumstances this might be useful to anyone. I certainly do know that no Derby users are using it this way as BOOLEAN was never returned in getTypeInfo() until now.

        I do think that quite a few applications use it the other way to see if BOOLEAN is available for user tables with the database they are working with and this bug will break those applications in soft upgrade mode, probably preventing those evaluating 10.7 from making the decision to move to 10.7. So I think it is a fairly serious regression that we now return BOOLEAN in getTypeInfo() with a database where it is not available. I am sorry to hear you are not interested in fixing it as part of the BOOLEAN data type work.

        Show
        Kathey Marsden added a comment - Thanks Rick for your insight. I want to understand your statement. "However, from the point of view of applications wanting to know what kind of datatypes they could SELECT, it was wrong for DatabaseMetaData.getTypeInfo() to omit the BOOLEAN datatype. " I was trying to think under what circumstances this might be useful to anyone. I certainly do know that no Derby users are using it this way as BOOLEAN was never returned in getTypeInfo() until now. I do think that quite a few applications use it the other way to see if BOOLEAN is available for user tables with the database they are working with and this bug will break those applications in soft upgrade mode, probably preventing those evaluating 10.7 from making the decision to move to 10.7. So I think it is a fairly serious regression that we now return BOOLEAN in getTypeInfo() with a database where it is not available. I am sorry to hear you are not interested in fixing it as part of the BOOLEAN data type work.
        Hide
        Rick Hillegas added a comment -

        Hi Kathey,

        The ability to SELECT boolean values is useful for applications which introspect Derby's metadata by issuing queries against the catalogs, compensating for the fact that we have not implemented the SQL Information Schema.

        I agree that the behavior has changed and it is a regression from the point of view of the applications you have described. From the point of view of other applications it is a bug-fix and an improvement.

        As I said, if you believe this is a serious problem for your customers, then you are welcome to revert the behavior. I will not veto that change.

        While you are at it, you may want to remove the XML datatype from the output of DatabaseMetaData.getTypeInfo(). It is another half-supported Derby datatype and it may be causing similar problems for the applications you are concerned about.

        Show
        Rick Hillegas added a comment - Hi Kathey, The ability to SELECT boolean values is useful for applications which introspect Derby's metadata by issuing queries against the catalogs, compensating for the fact that we have not implemented the SQL Information Schema. I agree that the behavior has changed and it is a regression from the point of view of the applications you have described. From the point of view of other applications it is a bug-fix and an improvement. As I said, if you believe this is a serious problem for your customers, then you are welcome to revert the behavior. I will not veto that change. While you are at it, you may want to remove the XML datatype from the output of DatabaseMetaData.getTypeInfo(). It is another half-supported Derby datatype and it may be causing similar problems for the applications you are concerned about.
        Hide
        Kathey Marsden added a comment -

        Well getBoolean() works on System table BOOLEAN regardless, so not so clear why that would be useful decision point but certainly clear to me that in the contexts where BOOLEAN is not supported the DatabaseMetaData should continue to not return it.

        I am glad to hear you would not veto someone fixing this regression but a bit perplexed that you would consider doing so.

        Show
        Kathey Marsden added a comment - Well getBoolean() works on System table BOOLEAN regardless, so not so clear why that would be useful decision point but certainly clear to me that in the contexts where BOOLEAN is not supported the DatabaseMetaData should continue to not return it. I am glad to hear you would not veto someone fixing this regression but a bit perplexed that you would consider doing so.
        Hide
        Knut Anders Hatlen added a comment -

        My gut feeling is that of the two wrong answers, saying that boolean is not supported in the soft-upgrade scenario is probably the one that does less harm. I see that the class-level javadoc for DatabaseMetaData mentions some use cases for the class, and one of them is the one in Kathey's repro:

        "For example, a tool might use the method getTypeInfo to find out what data types can be used in a CREATE TABLE statement."

        I have a hard time imagining an application that would run into trouble if we removed boolean from getTypeInfo() in soft upgrade. We've had the situation with a half boolean data type and no mentioning of boolean in getTypeInfo() for a very long time, and no problems have been reported because of it as far as I know, so I believe such a change would be pretty safe to make.

        Show
        Knut Anders Hatlen added a comment - My gut feeling is that of the two wrong answers, saying that boolean is not supported in the soft-upgrade scenario is probably the one that does less harm. I see that the class-level javadoc for DatabaseMetaData mentions some use cases for the class, and one of them is the one in Kathey's repro: "For example, a tool might use the method getTypeInfo to find out what data types can be used in a CREATE TABLE statement." I have a hard time imagining an application that would run into trouble if we removed boolean from getTypeInfo() in soft upgrade. We've had the situation with a half boolean data type and no mentioning of boolean in getTypeInfo() for a very long time, and no problems have been reported because of it as far as I know, so I believe such a change would be pretty safe to make.
        Hide
        Rick Hillegas added a comment -

        There were many problems with Cloudscape's original BOOLEAN datatype. I have fixed the ones I knew about. Additional problems were introduced when BOOLEAN was removed as a datatype usable in CREATE TABLE statements. One of those problems was the introduction of a metadata discrepancy between getTypeInfo() and getColumns(). It seems wrong to me that DatabaseMetaData().getColumns() can return datatypes which do not appear in the list returned by getTypeInfo().

        However, I agree with Knut's final statement: Our users have learned how to code around this discrepancy, and reverting the behavior is a low risk change.

        Show
        Rick Hillegas added a comment - There were many problems with Cloudscape's original BOOLEAN datatype. I have fixed the ones I knew about. Additional problems were introduced when BOOLEAN was removed as a datatype usable in CREATE TABLE statements. One of those problems was the introduction of a metadata discrepancy between getTypeInfo() and getColumns(). It seems wrong to me that DatabaseMetaData().getColumns() can return datatypes which do not appear in the list returned by getTypeInfo(). However, I agree with Knut's final statement: Our users have learned how to code around this discrepancy, and reverting the behavior is a low risk change.
        Hide
        Kathey Marsden added a comment -

        Yes I think the only risk in fixing it could be if someone started depending on the new behavior. Since I think we do not currently have infrastructure for a variable query for DatabaseMetaData, a fix might be hard, and there doesn't seem to be anyone with bandwidth to fix it right now, so I think it would make sense to add a release note to DERBY-4730 pointing to this bug and indicating that BOOLEAN will be removed from getTypeInfo() as soon as this issue is fixed. It might also be helpful to users that encounter the issue in the repro. I am not exactly sure how they could work around that problem with Generic JDBC code or even with something specific to Derby. We have the open issue https://issues.apache.org/jira/browse/DERBY-4259 which would work but that is not fixed yet. Does anyone have ideas how users can work around this issue and recognize if the database is in soft upgrade mode and whether BOOLEAN is actually available to create a table? Then we could add that to the release note too.

        Thanks

        Kathey

        Show
        Kathey Marsden added a comment - Yes I think the only risk in fixing it could be if someone started depending on the new behavior. Since I think we do not currently have infrastructure for a variable query for DatabaseMetaData, a fix might be hard, and there doesn't seem to be anyone with bandwidth to fix it right now, so I think it would make sense to add a release note to DERBY-4730 pointing to this bug and indicating that BOOLEAN will be removed from getTypeInfo() as soon as this issue is fixed. It might also be helpful to users that encounter the issue in the repro. I am not exactly sure how they could work around that problem with Generic JDBC code or even with something specific to Derby. We have the open issue https://issues.apache.org/jira/browse/DERBY-4259 which would work but that is not fixed yet. Does anyone have ideas how users can work around this issue and recognize if the database is in soft upgrade mode and whether BOOLEAN is actually available to create a table? Then we could add that to the release note too. Thanks Kathey
        Hide
        Knut Anders Hatlen added a comment -

        The easiest way to see if they can create a table with a BOOLEAN column, would be to attempt to create a table with a BOOLEAN column and see if that fails.

        Show
        Knut Anders Hatlen added a comment - The easiest way to see if they can create a table with a BOOLEAN column, would be to attempt to create a table with a BOOLEAN column and see if that fails.
        Hide
        Knut Anders Hatlen added a comment -

        I think the attached patch will change the behaviour of getTypeInfo() as suggested and only return BOOLEAN if the data dictionary is at version 10.7 or higher.

        Show
        Knut Anders Hatlen added a comment - I think the attached patch will change the behaviour of getTypeInfo() as suggested and only return BOOLEAN if the data dictionary is at version 10.7 or higher.
        Knut Anders Hatlen made changes -
        Attachment bool.diff [ 12466492 ]
        Hide
        Rick Hillegas added a comment -

        The patch looks good to me. Thanks, Knut.

        Show
        Rick Hillegas added a comment - The patch looks good to me. Thanks, Knut.
        Hide
        Knut Anders Hatlen added a comment -

        I first didn't notice that the query was also used by the ODBC variant of getTypeInfo(). The attached patch fixes that problem. In addition it adds a test case to the upgrade tests, and changes the test case for getTypeInfo() in DatabaseMetaDataTest to account for the new behaviour in soft upgrade (DatabaseMetaDataTest is run by the upgrade tests).

        I have only run the upgrade tests on this patch, and only with 10.6.2.1 and 10.7.1.1 against trunk.

        Show
        Knut Anders Hatlen added a comment - I first didn't notice that the query was also used by the ODBC variant of getTypeInfo(). The attached patch fixes that problem. In addition it adds a test case to the upgrade tests, and changes the test case for getTypeInfo() in DatabaseMetaDataTest to account for the new behaviour in soft upgrade (DatabaseMetaDataTest is run by the upgrade tests). I have only run the upgrade tests on this patch, and only with 10.6.2.1 and 10.7.1.1 against trunk.
        Knut Anders Hatlen made changes -
        Attachment odbc+tests.diff [ 12466499 ]
        Knut Anders Hatlen made changes -
        Assignee Knut Anders Hatlen [ knutanders ]
        Hide
        Kathey Marsden added a comment -

        Yay, Knut! One less worry! I did not have a chance to apply the patch but looked at it and looks good to me.

        Show
        Kathey Marsden added a comment - Yay, Knut! One less worry! I did not have a chance to apply the patch but looked at it and looks good to me.
        Knut Anders Hatlen made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        Knut Anders Hatlen added a comment -

        Thanks, Rick and Kathey, for looking at the patches. Committed revision 1051026.

        I'll backport it to 10.7 too (after running tests). Since this fix alters the meta-data queries, I suppose I need to bump the last digit in the version number on the branch too?

        Show
        Knut Anders Hatlen added a comment - Thanks, Rick and Kathey, for looking at the patches. Committed revision 1051026. I'll backport it to 10.7 too (after running tests). Since this fix alters the meta-data queries, I suppose I need to bump the last digit in the version number on the branch too?
        Hide
        Rick Hillegas added a comment -

        Hi Knut. What scenario are you handling by bumping the last digit?

        Show
        Rick Hillegas added a comment - Hi Knut. What scenario are you handling by bumping the last digit?
        Hide
        Knut Anders Hatlen added a comment -

        If someone is running from head of 10.7 because they need one of the fixes that went in after 10.7.1.1, they won't get the SPS for getTypeInfo() invalidated when they pull in this fix. Since the number of parameters in the SPS has changed, they'll get an error when executing getTypeInfo() if the SPS isn't invalidated and recompiled. A recompile of the SPS will happen if the version is bumped.

        For example, create a new database and execute getTypeInfo() with head of 10.7. Then apply this fix and run getTypeInfo() again, and you'll see something like this:

        Exception in thread "main" java.sql.SQLException: No input parameters.
        at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
        at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:256)
        at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:396)
        at org.apache.derby.impl.jdbc.EmbedResultSet.noStateChangeException(EmbedResultSet.java:4454)
        at org.apache.derby.impl.jdbc.EmbedPreparedStatement.setBoolean(EmbedPreparedStatement.java:363)
        at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getTypeInfoMinion(EmbedDatabaseMetaData.java:2724)
        at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getTypeInfo(EmbedDatabaseMetaData.java:2696)
        at GetTypeInfo.main(GetTypeInfo.java:5)
        Caused by: java.sql.SQLException: No input parameters.
        at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
        at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:119)
        at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70)
        ... 7 more
        Caused by: ERROR 07009: No input parameters.
        at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:276)
        at org.apache.derby.impl.sql.GenericParameterValueSet.checkPosition(GenericParameterValueSet.java:319)
        at org.apache.derby.impl.sql.GenericParameterValueSet.getParameterForSet(GenericParameterValueSet.java:166)
        at org.apache.derby.impl.jdbc.EmbedPreparedStatement.setBoolean(EmbedPreparedStatement.java:360)
        ... 3 more

        Show
        Knut Anders Hatlen added a comment - If someone is running from head of 10.7 because they need one of the fixes that went in after 10.7.1.1, they won't get the SPS for getTypeInfo() invalidated when they pull in this fix. Since the number of parameters in the SPS has changed, they'll get an error when executing getTypeInfo() if the SPS isn't invalidated and recompiled. A recompile of the SPS will happen if the version is bumped. For example, create a new database and execute getTypeInfo() with head of 10.7. Then apply this fix and run getTypeInfo() again, and you'll see something like this: Exception in thread "main" java.sql.SQLException: No input parameters. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:256) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:396) at org.apache.derby.impl.jdbc.EmbedResultSet.noStateChangeException(EmbedResultSet.java:4454) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.setBoolean(EmbedPreparedStatement.java:363) at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getTypeInfoMinion(EmbedDatabaseMetaData.java:2724) at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getTypeInfo(EmbedDatabaseMetaData.java:2696) at GetTypeInfo.main(GetTypeInfo.java:5) Caused by: java.sql.SQLException: No input parameters. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:119) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) ... 7 more Caused by: ERROR 07009: No input parameters. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:276) at org.apache.derby.impl.sql.GenericParameterValueSet.checkPosition(GenericParameterValueSet.java:319) at org.apache.derby.impl.sql.GenericParameterValueSet.getParameterForSet(GenericParameterValueSet.java:166) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.setBoolean(EmbedPreparedStatement.java:360) ... 3 more
        Hide
        Rick Hillegas added a comment -

        Thanks, Knut. Bumping the last digit makes sense for those users. +1.

        Show
        Rick Hillegas added a comment - Thanks, Knut. Bumping the last digit makes sense for those users. +1.
        Hide
        Rick Hillegas added a comment -

        I bumped the last digit of the release id on the 10.7 branch and changed the name of the head of the branch to 10.7.1.3.

        Show
        Rick Hillegas added a comment - I bumped the last digit of the release id on the 10.7 branch and changed the name of the head of the branch to 10.7.1.3.
        Hide
        Knut Anders Hatlen added a comment -

        Thanks, Rick. Backported the fix to 10.7 and committed revision 1051148. Hopefully the window between your commit and mine wasn't so big that someone runs into this problem.

        Show
        Knut Anders Hatlen added a comment - Thanks, Rick. Backported the fix to 10.7 and committed revision 1051148. Hopefully the window between your commit and mine wasn't so big that someone runs into this problem.
        Knut Anders Hatlen made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Fix Version/s 10.7.1.3 [ 12315902 ]
        Fix Version/s 10.8.0.0 [ 12315561 ]
        Resolution Fixed [ 1 ]
        Kathey Marsden made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Rick Hillegas made changes -
        Affects Version/s 10.8.1.1 [ 12316356 ]
        Affects Version/s 10.8.1.0 [ 12315561 ]
        Fix Version/s 10.8.1.1 [ 12316356 ]
        Fix Version/s 10.8.1.0 [ 12315561 ]
        Rick Hillegas made changes -
        Affects Version/s 10.8.1.2 [ 12316362 ]
        Affects Version/s 10.8.1.1 [ 12316356 ]
        Fix Version/s 10.8.1.2 [ 12316362 ]
        Fix Version/s 10.8.1.1 [ 12316356 ]
        Gavin made changes -
        Workflow jira [ 12540288 ] Default workflow, editable Closed status [ 12801039 ]

          People

          • Assignee:
            Knut Anders Hatlen
            Reporter:
            Kathey Marsden
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development