Derby
  1. Derby
  2. DERBY-4282

strange behavior with the "update ... where current of c1" in the CheckConstraintTest

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 10.0.2.1, 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.1.1
    • Fix Version/s: 10.5.3.2, 10.6.1.0
    • Component/s: SQL
    • Labels:
      None
    • Urgency:
      Normal
    • Issue & fix info:
      Newcomer, Repro attached

      Description

      import java.sql.*;

      public class cons
      {
      public static void main(String []args)
      throws Exception

      { Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance(); Connection conn = DriverManager.getConnection("jdbc:derby:testdb;create=true"); Statement st = conn.createStatement(); st.executeUpdate( "create table t1(c1 int, c2 int, constraint ck1 " + "check(c1 = c2), constraint ck2 check(c2=c1))"); st.executeUpdate("insert into t1 values (1, 1),(2, 2),(3, 3),(4, 4)"); Statement st1=conn.createStatement(); st1.setCursorName("c1"); ResultSet rs = st1.executeQuery("select * from t1 for update"); rs.next(); st.executeUpdate("update t1 set c1 = c1 where current of \"c1\""); }

      }
      Exception in thread "main" java.sql.SQLException: Column 'C2' is either not in any
      table in the FROM list or appears within a join specification and is outside
      the scope of the join specification or appears in a HAVING clause and is not in
      the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'C2' is not
      a column in the target table.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExc
      eptionFactory.java:45)
      at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:201)

      at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException
      (TransactionResourceImpl.java:391)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Tr
      ansactionResourceImpl.java:346)
      at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConne
      ction.java:2201)
      at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Connection
      Child.java:81)
      at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java
      :614)
      at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatemen
      t.java:175)
      at cons.main(cons.java:25)

      Caused by: ERROR 42X04: Column 'C2' is either not in any table in the FROM list
      or appears within a join specification and is outside the scope of the join spec

      • Show quoted text -
        ... 2 more
      1. ASF.LICENSE.NOT.GRANTED--DERBY4282.diff
        5 kB
        Eranda Sooriyabandara
      2. ASF.LICENSE.NOT.GRANTED--DERBY4282.diff
        2 kB
        Eranda Sooriyabandara
      3. cons.java
        0.8 kB
        Bryan Pendleton

        Issue Links

          Activity

          Eranda Sooriyabandara created issue -
          Eranda Sooriyabandara made changes -
          Field Original Value New Value
          Link This issue is blocked by DERBY-4248 [ DERBY-4248 ]
          Eranda Sooriyabandara made changes -
          Link This issue is blocked by DERBY-4248 [ DERBY-4248 ]
          Eranda Sooriyabandara made changes -
          Link This issue blocks DERBY-4248 [ DERBY-4248 ]
          Hide
          Bryan Pendleton added a comment -

          Dag Wanvik posted an alternate reproduction case to the derby-dev list:

          Another data point.

          This also fails when using updatable result set, as could be expected
          since it uses an underlying cursor:

          Statement st1=conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE);
          st1.setCursorName("c1");
          ResultSet rs = st1.executeQuery("select * from t1 for update");
          rs.next();
          rs.updateInt(1, rs.getInt(1));
          rs.updateRow();

          Caused by: ERROR 42X04: Column 'C2' is either not in any table in the FROM list or appears within a join specification and is outside the scope of the join specification or appears in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'C2' is not a column in the target table.
          at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
          at org.apache.derby.impl.sql.compile.ColumnReference.bindExpression(ColumnReference.java:354)
          at org.apache.derby.impl.sql.compile.BinaryOperatorNode.bindExpression(BinaryOperatorNode.java:298)
          at org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindExpression(BinaryComparisonOperatorNode.java:133)
          at org.apache.derby.impl.sql.compile.UnaryOperatorNode.bindOperand(UnaryOperatorNode.java:333)
          at org.apache.derby.impl.sql.compile.TestConstraintNode.bindExpression(TestConstraintNode.java:92)
          at org.apache.derby.impl.sql.compile.BinaryOperatorNode.bindExpression(BinaryOperatorNode.java:298)
          at org.apache.derby.impl.sql.compile.BinaryLogicalOperatorNode.bindExpression(BinaryLogicalOperatorNode.java:94)
          at org.apache.derby.impl.sql.compile.AndNode.bindExpression(AndNode.java:68)
          at org.apache.derby.impl.sql.compile.DMLModStatementNode.bindRowScopedExpression(DMLModStatementNode.java:809)
          at org.apache.derby.impl.sql.compile.DMLModStatementNode.bindConstraints(DMLModStatementNode.java:735)
          at org.apache.derby.impl.sql.compile.UpdateNode.bindStatement(UpdateNode.java:618)
          at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:316)
          at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:80)
          at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:831)
          at org.apache.derby.impl.jdbc.EmbedResultSet.updateRow(EmbedResultSet.java:3710)
          ... 1 more

          Show
          Bryan Pendleton added a comment - Dag Wanvik posted an alternate reproduction case to the derby-dev list: Another data point. This also fails when using updatable result set, as could be expected since it uses an underlying cursor: Statement st1=conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE); st1.setCursorName("c1"); ResultSet rs = st1.executeQuery("select * from t1 for update"); rs.next(); rs.updateInt(1, rs.getInt(1)); rs.updateRow(); Caused by: ERROR 42X04: Column 'C2' is either not in any table in the FROM list or appears within a join specification and is outside the scope of the join specification or appears in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'C2' is not a column in the target table. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286) at org.apache.derby.impl.sql.compile.ColumnReference.bindExpression(ColumnReference.java:354) at org.apache.derby.impl.sql.compile.BinaryOperatorNode.bindExpression(BinaryOperatorNode.java:298) at org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindExpression(BinaryComparisonOperatorNode.java:133) at org.apache.derby.impl.sql.compile.UnaryOperatorNode.bindOperand(UnaryOperatorNode.java:333) at org.apache.derby.impl.sql.compile.TestConstraintNode.bindExpression(TestConstraintNode.java:92) at org.apache.derby.impl.sql.compile.BinaryOperatorNode.bindExpression(BinaryOperatorNode.java:298) at org.apache.derby.impl.sql.compile.BinaryLogicalOperatorNode.bindExpression(BinaryLogicalOperatorNode.java:94) at org.apache.derby.impl.sql.compile.AndNode.bindExpression(AndNode.java:68) at org.apache.derby.impl.sql.compile.DMLModStatementNode.bindRowScopedExpression(DMLModStatementNode.java:809) at org.apache.derby.impl.sql.compile.DMLModStatementNode.bindConstraints(DMLModStatementNode.java:735) at org.apache.derby.impl.sql.compile.UpdateNode.bindStatement(UpdateNode.java:618) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:316) at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:80) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:831) at org.apache.derby.impl.jdbc.EmbedResultSet.updateRow(EmbedResultSet.java:3710) ... 1 more
          Dag H. Wanvik made changes -
          Issue & fix info [Newcomer]
          Hide
          Dag H. Wanvik added a comment -

          Triaged for 10.5.2, checking "repro attached".

          Show
          Dag H. Wanvik added a comment - Triaged for 10.5.2, checking "repro attached".
          Dag H. Wanvik made changes -
          Issue & fix info [Newcomer] [Newcomer, Repro attached]
          Dag H. Wanvik made changes -
          Affects Version/s 10.4.2.0 [ 12313345 ]
          Affects Version/s 10.3.3.0 [ 12313142 ]
          Affects Version/s 10.2.2.0 [ 12312027 ]
          Affects Version/s 10.1.3.1 [ 12311953 ]
          Affects Version/s 10.0.2.1 [ 10991 ]
          Hide
          Eranda Sooriyabandara added a comment -

          Hi Bryan,
          In,
          Statement st1=conn.createStatement();
          st1.setCursorName("c1");
          ResultSet rs = st1.executeQuery("select * from t1 for update");
          rs.next();
          st.executeUpdate("update t1 set c1 = c1 where current of \"c1\"");

          I think it should add autoCommit(false); statement.
          Because when I try to test when autocommit on, i got the message
          ij> update t1 set c1 = c1 where current of c1;
          ERROR 42X30: Cursor 'C1' not found. Verify that autocommit is OFF.
          When autocommit off; this succeeds.

          But I am confused with it because the error message includes that c2 is not
          there, because we don't consider c2 here.

          "Exception in thread "main" java.sql.SQLException: Column 'C2' is either not
          in any
          table in the FROM list or appears within a join specification and is
          outside
          the scope of the join specification or appears in a HAVING clause and is not
          in
          the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'C2' is
          not
          a column in the target table."

          Why it is show autocommit must off when we setCommit(false)?

          Thanks
          Eranda

          Show
          Eranda Sooriyabandara added a comment - Hi Bryan, In, Statement st1=conn.createStatement(); st1.setCursorName("c1"); ResultSet rs = st1.executeQuery("select * from t1 for update"); rs.next(); st.executeUpdate("update t1 set c1 = c1 where current of \"c1\""); I think it should add autoCommit(false); statement. Because when I try to test when autocommit on, i got the message ij> update t1 set c1 = c1 where current of c1; ERROR 42X30: Cursor 'C1' not found. Verify that autocommit is OFF. When autocommit off; this succeeds. But I am confused with it because the error message includes that c2 is not there, because we don't consider c2 here. "Exception in thread "main" java.sql.SQLException: Column 'C2' is either not in any table in the FROM list or appears within a join specification and is outside the scope of the join specification or appears in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'C2' is not a column in the target table." Why it is show autocommit must off when we setCommit(false)? Thanks Eranda
          Hide
          Bryan Pendleton added a comment -

          I tried adding

          conn.setAutoCommit(false);

          to the test, but it didn't seem to change the behavior for me.

          Attached is the 'cons.java' that I tried.

          Show
          Bryan Pendleton added a comment - I tried adding conn.setAutoCommit(false); to the test, but it didn't seem to change the behavior for me. Attached is the 'cons.java' that I tried.
          Bryan Pendleton made changes -
          Attachment cons.java [ 12413209 ]
          Hide
          Bryan Pendleton added a comment -

          I spent some time stepping through this code and trying to figure out what's going on.
          Here are some notes on what I learned:

          1) Firstly, here are some observations on possible workarounds:
          a) If we change the line
          st.executeUpdate("update t1 set c1 = c1 where current of \"c1\"");
          to
          st.executeUpdate("update t1 set c1 = c1,c2=c2 where current of \"c1\"");
          then the problem does not occur
          b) If we, alternately, change the line
          ResultSet rs = st1.executeQuery("select * from t1 for update");
          to
          ResultSet rs = st1.executeQuery("select * from t1 for update of c1,c2");
          then the problem does not occur.
          c) Similarly, if we change
          ResultSet rs = st1.executeQuery("select * from t1 for update");
          to
          ResultSet rs = st1.executeQuery("select * from t1 for update of c1");
          then the problem does not occur.

          2) Secondly, if we change
          ResultSet rs = st1.executeQuery("select * from t1 for update");
          to
          ResultSet rs = st1.executeQuery("select * from t1 for update of c2");
          Then we get, correctly I believe, the following error:

          Exception in thread "main" java.sql.SQLSyntaxErrorException: Column 'C1' is not
          in the FOR UPDATE list of cursor 'c1'.

          Regardless of how we fix this Jira issue, I think that the 4 above test cases, as well
          as the test case in the issue description, should be added to our regression suites.

          3) I spent some time stepping through the code in the debugger, and I believe that the
          problem arises around line 435 of UpdateNode.java, where we find this code:

          /*

            • Add the "after" portion of the result row. This is the update
            • list augmented to include every column in the target table.
            • Those columns that are not being updated are set to themselves.
            • The expanded list will be in the order of the columns in the base
            • table.
              */
              afterColumns = resultSet.getResultColumns().expandToAll(
              targetTableDescriptor,
              targetTable.getTableName());

          We then arrive at line 2546 of ResultColumnList.java, where we find this code:

          /* Build a ResultColumn/ColumnReference pair for the column */
          rc = makeColumnReferenceFromName( tableName, cd.getColumnName() );

          And then we get to line 4070 of ResultColumnList.java, where we find this code:

          ResultColumn rc = (ResultColumn) nodeFactory.getNode
          (
          C_NodeTypes.RESULT_COLUMN,
          null,
          nodeFactory.getNode
          (
          C_NodeTypes.COLUMN_REFERENCE,
          columnName,
          tableName,
          cm
          ),
          cm
          );

          I think that the problem involves the 'null' that we pass as the first argument
          to the ResultColumn initialization logic, because this causes the generated 'C2' column
          that is pulled from the 'select *' cursor into the 'update' statement to be pulled
          as an UNNAMED column, which is (later) transformed into a column named 'SQLCOL1',
          and ends up resulting in a bind failure for the CHECK constraint, which can't find
          column 'C2' in the ResultColumnList, finding instead the columns 'C1' and 'SQLCOL1'.

          I think the fix may be as simple as changing 'null' to 'columnName', as in this diff:

          Index: java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java
          ===================================================================
          — java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java (revision 787523)
          +++ java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java (working copy)
          @@ -4057,7 +4057,7 @@
          ResultColumn rc = (ResultColumn) nodeFactory.getNode
          (
          C_NodeTypes.RESULT_COLUMN,

          • null,
            + columnName,
            nodeFactory.getNode
            (
            C_NodeTypes.COLUMN_REFERENCE,

          I did some very simple testing, and this appeared to fix the reproduction case, but
          I have not run any other regression tests.

          I think that the next steps here ought to be to construct a proper patch, containing:
          1) the code change to ResultColumnList.java
          2) the necessary changes to CheckConstraintTest.java to include the bug script
          from the issue description, together with the additional test cases I
          mentioned above
          and then to run a complete set of regression tests to see if the code change
          causes any other problems with Derby.

          Show
          Bryan Pendleton added a comment - I spent some time stepping through this code and trying to figure out what's going on. Here are some notes on what I learned: 1) Firstly, here are some observations on possible workarounds: a) If we change the line st.executeUpdate("update t1 set c1 = c1 where current of \"c1\""); to st.executeUpdate("update t1 set c1 = c1,c2=c2 where current of \"c1\""); then the problem does not occur b) If we, alternately, change the line ResultSet rs = st1.executeQuery("select * from t1 for update"); to ResultSet rs = st1.executeQuery("select * from t1 for update of c1,c2"); then the problem does not occur. c) Similarly, if we change ResultSet rs = st1.executeQuery("select * from t1 for update"); to ResultSet rs = st1.executeQuery("select * from t1 for update of c1"); then the problem does not occur. 2) Secondly, if we change ResultSet rs = st1.executeQuery("select * from t1 for update"); to ResultSet rs = st1.executeQuery("select * from t1 for update of c2"); Then we get, correctly I believe, the following error: Exception in thread "main" java.sql.SQLSyntaxErrorException: Column 'C1' is not in the FOR UPDATE list of cursor 'c1'. Regardless of how we fix this Jira issue, I think that the 4 above test cases, as well as the test case in the issue description, should be added to our regression suites. 3) I spent some time stepping through the code in the debugger, and I believe that the problem arises around line 435 of UpdateNode.java, where we find this code: /* Add the "after" portion of the result row. This is the update list augmented to include every column in the target table. Those columns that are not being updated are set to themselves. The expanded list will be in the order of the columns in the base table. */ afterColumns = resultSet.getResultColumns().expandToAll( targetTableDescriptor, targetTable.getTableName()); We then arrive at line 2546 of ResultColumnList.java, where we find this code: /* Build a ResultColumn/ColumnReference pair for the column */ rc = makeColumnReferenceFromName( tableName, cd.getColumnName() ); And then we get to line 4070 of ResultColumnList.java, where we find this code: ResultColumn rc = (ResultColumn) nodeFactory.getNode ( C_NodeTypes.RESULT_COLUMN, null, nodeFactory.getNode ( C_NodeTypes.COLUMN_REFERENCE, columnName, tableName, cm ), cm ); I think that the problem involves the 'null' that we pass as the first argument to the ResultColumn initialization logic, because this causes the generated 'C2' column that is pulled from the 'select *' cursor into the 'update' statement to be pulled as an UNNAMED column, which is (later) transformed into a column named 'SQLCOL1', and ends up resulting in a bind failure for the CHECK constraint, which can't find column 'C2' in the ResultColumnList, finding instead the columns 'C1' and 'SQLCOL1'. I think the fix may be as simple as changing 'null' to 'columnName', as in this diff: Index: java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java =================================================================== — java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java (revision 787523) +++ java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java (working copy) @@ -4057,7 +4057,7 @@ ResultColumn rc = (ResultColumn) nodeFactory.getNode ( C_NodeTypes.RESULT_COLUMN, null, + columnName, nodeFactory.getNode ( C_NodeTypes.COLUMN_REFERENCE, I did some very simple testing, and this appeared to fix the reproduction case, but I have not run any other regression tests. I think that the next steps here ought to be to construct a proper patch, containing: 1) the code change to ResultColumnList.java 2) the necessary changes to CheckConstraintTest.java to include the bug script from the issue description, together with the additional test cases I mentioned above and then to run a complete set of regression tests to see if the code change causes any other problems with Derby.
          Eranda Sooriyabandara made changes -
          Attachment DERBY4282.diff [ 12416159 ]
          Hide
          Eranda Sooriyabandara added a comment -

          Hi Bryan,
          I test with your update and found some problems,

          1.When I use the code as,

          Statement st1 = conn.createStatement();
          st1.setCursorName("c1");
          ResultSet rs1 = st1.executeQuery("elect * from t1 where c2 = 2 for
          update of c1");
          rs1.next();
          st.executeUpdate("update t1 set c1 = c1 where current of \"c1\"");
          assertStatementError("23513", st,
          "update t1 set c1 = c1 + 1 where current of \"c1\"");

          it is successfully working but when I change the code as,

          Statement st1 = conn.createStatement();
          st1.setCursorName("c1");
          ResultSet rs1 = st1.executeQuery("select * from t1 where c2 = 2 for
          update of c1");
          rs1.next();
          expRS=new String[][]{

          {"2","2"}
          };
          JDBC.assertFullResultSet(rs1, expRS);
          st.executeUpdate("update t1 set c1 = c1 where current of \"c1\"");
          assertStatementError("23513", st,
          "update t1 set c1 = c1 + 1 where current of \"c1\"");

          It gave me the error "unexpected row count:expected<1> but was<0>" in the
          line of "JDBC.assertFullResultSet(rs1, expRS);";.

          I think this is because in the JDBC they called the rs.next() until it's
          become false. So the cursor ends from there.
          When we reach the line "st.executeUpdate("update t1 set c1 = c1 where
          current of \"c1\"");" cursor not available. So we can't use both of them
          together. I thought to skip the part of,
          expRS=new String[][]{
          {"2","2"}

          };
          JDBC.assertFullResultSet(rs1, expRS);
          from the code.

          So I try a method which successful at the end.I send it as a patch file
          here.
          If it is fine for you then I can do as the same thing for the rest of the
          commented codes.

          Show
          Eranda Sooriyabandara added a comment - Hi Bryan, I test with your update and found some problems, 1.When I use the code as, Statement st1 = conn.createStatement(); st1.setCursorName("c1"); ResultSet rs1 = st1.executeQuery("elect * from t1 where c2 = 2 for update of c1"); rs1.next(); st.executeUpdate("update t1 set c1 = c1 where current of \"c1\""); assertStatementError("23513", st, "update t1 set c1 = c1 + 1 where current of \"c1\""); it is successfully working but when I change the code as, Statement st1 = conn.createStatement(); st1.setCursorName("c1"); ResultSet rs1 = st1.executeQuery("select * from t1 where c2 = 2 for update of c1"); rs1.next(); expRS=new String[][]{ {"2","2"} }; JDBC.assertFullResultSet(rs1, expRS); st.executeUpdate("update t1 set c1 = c1 where current of \"c1\""); assertStatementError("23513", st, "update t1 set c1 = c1 + 1 where current of \"c1\""); It gave me the error "unexpected row count:expected<1> but was<0>" in the line of "JDBC.assertFullResultSet(rs1, expRS);";. I think this is because in the JDBC they called the rs.next() until it's become false. So the cursor ends from there. When we reach the line "st.executeUpdate("update t1 set c1 = c1 where current of \"c1\"");" cursor not available. So we can't use both of them together. I thought to skip the part of, expRS=new String[][]{ {"2","2"} }; JDBC.assertFullResultSet(rs1, expRS); from the code. So I try a method which successful at the end.I send it as a patch file here. If it is fine for you then I can do as the same thing for the rest of the commented codes.
          Eranda Sooriyabandara made changes -
          Attachment DERBY4282.diff [ 12416160 ]
          Eranda Sooriyabandara made changes -
          Comment [ Hi Bryan,Here I am attaching the full patch that I edited for your concern.
          ]
          Eranda Sooriyabandara made changes -
          Attachment DERBY4282.diff [ 12416159 ]
          Hide
          Eranda Sooriyabandara added a comment -

          Hi Bryan,Here I am attaching the full patch that I edited for your concern.

          Show
          Eranda Sooriyabandara added a comment - Hi Bryan,Here I am attaching the full patch that I edited for your concern.
          Eranda Sooriyabandara made changes -
          Attachment DERBY4282.diff [ 12416161 ]
          Hide
          Bryan Pendleton added a comment -

          The important part of the test is to verify that the check constraint is enforced
          properly for the "where current of" style of the update statement when the cursor is open.

          So we don't need to call JDBC.assertFullResultSet on the SELECT statement, I agree.
          The only reason we are issuing the SELECT statement and calling rs1.next() is to
          ensure that the cursor is opened.

          So your technique looks fine to me.

          Is that the only remaining issue for this patch?

          Show
          Bryan Pendleton added a comment - The important part of the test is to verify that the check constraint is enforced properly for the "where current of" style of the update statement when the cursor is open. So we don't need to call JDBC.assertFullResultSet on the SELECT statement, I agree. The only reason we are issuing the SELECT statement and calling rs1.next() is to ensure that the cursor is opened. So your technique looks fine to me. Is that the only remaining issue for this patch?
          Hide
          Eranda Sooriyabandara added a comment -

          Hi Bryan,
          Yes,that's all in the test part. Can we commit it now?
          Thanks

          Show
          Eranda Sooriyabandara added a comment - Hi Bryan, Yes,that's all in the test part. Can we commit it now? Thanks
          Hide
          Bryan Pendleton added a comment -

          I included the test case from the issue description into CheckConstraintTest, because that
          test case was very clear and simple and I wanted to preserve it in the test suite. And I verified
          that CheckConstraintTest fails as expected without the code patch to ResultColumnList,
          and succeeds once the code patch to ResultColumnList is applied.

          I also ran a complete set of regression tests and didn't find any other problems, and I have
          committed the patch to svn as revision 803336.

          Eranda, thanks very much for contributing this bug fix to Derby.

          Show
          Bryan Pendleton added a comment - I included the test case from the issue description into CheckConstraintTest, because that test case was very clear and simple and I wanted to preserve it in the test suite. And I verified that CheckConstraintTest fails as expected without the code patch to ResultColumnList, and succeeds once the code patch to ResultColumnList is applied. I also ran a complete set of regression tests and didn't find any other problems, and I have committed the patch to svn as revision 803336. Eranda, thanks very much for contributing this bug fix to Derby.
          Bryan Pendleton made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 10.6.0.0 [ 12313727 ]
          Fix Version/s 10.5.1.1 [ 12313771 ]
          Resolution Fixed [ 1 ]
          Hide
          Eranda Sooriyabandara added a comment -

          Hi Bryan,Thanks for the updates and the committing and it's my pleasure to
          have more codes in DERBY with my contribution.
          I am closing this issue.

          Show
          Eranda Sooriyabandara added a comment - Hi Bryan,Thanks for the updates and the committing and it's my pleasure to have more codes in DERBY with my contribution. I am closing this issue.
          Eranda Sooriyabandara made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Kathey Marsden made changes -
          Link This issue is required by DERBY-4994 [ DERBY-4994 ]
          Hide
          Kathey Marsden added a comment -

          Reopen for backport.

          Show
          Kathey Marsden added a comment - Reopen for backport.
          Kathey Marsden made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Hide
          Kathey Marsden added a comment -

          Assigning to myself temporarily for backport.

          Show
          Kathey Marsden added a comment - Assigning to myself temporarily for backport.
          Kathey Marsden made changes -
          Assignee Eranda Sooriyabandara [ eranda ] Kathey Marsden [ kmarsden ]
          Hide
          Kathey Marsden added a comment -

          Resolving after port to 10.5. Thank you Eranda for the fix!

          Show
          Kathey Marsden added a comment - Resolving after port to 10.5. Thank you Eranda for the fix!
          Kathey Marsden made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Assignee Kathey Marsden [ kmarsden ] Eranda Sooriyabandara [ eranda ]
          Fix Version/s 10.5.3.2 [ 12315436 ]
          Resolution Fixed [ 1 ]
          Gavin made changes -
          Link This issue blocks DERBY-4248 [ DERBY-4248 ]
          Gavin made changes -
          Link This issue is depended upon by DERBY-4248 [ DERBY-4248 ]
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update] Close all resolved issues that haven't been updated for more than one year.

          Show
          Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.
          Knut Anders Hatlen made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Workflow jira [ 12466438 ] Default workflow, editable Closed status [ 12799593 ]

            People

            • Assignee:
              Eranda Sooriyabandara
              Reporter:
              Eranda Sooriyabandara
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development