You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by ma...@apache.org on 2011/03/26 01:19:02 UTC
svn commit: r1085613 - in
/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests:
Changes10_8.java UpgradeChange.java UpgradeRun.java
Author: mamta
Date: Sat Mar 26 00:19:02 2011
New Revision: 1085613
URL: http://svn.apache.org/viewvc?rev=1085613&view=rev
Log:
DERBY-5121 Data corruption when executing an UPDATE trigger
Changes made for DERBY-1482 caused corruption which is being worked
under DERBY-5121. The issue is that the generated trigger action
sql could be looking for columns (by positions, not names) in
incorrect positions. With DERBY-1482, trigger assumed that the
runtime resultset that they will get will only have trigger columns
and trigger action columns used through the REFERENCING column.
That is an incorrect assumption because the resultset could have
more columns if the triggering sql requires more columns. DERBY-1482
changes are in 10.7 and higher codelines. Because of this bug, the
changes for DERBY-1482 have been backed out from 10.7 and 10.8
codelines so they now match 10.6 and earlier releases. This in
other words means that the resultset presented to the trigger
will have all the columns from the trigger table and the trigger
action generated sql should look for the columns in the trigger
table by their absolution column position in the trigger table.
This disabling of code will make sure that all the future triggers
get created correctly. The existing triggers at the time of
upgrade (to the releases with DERBY-1482 backout changes in them)
will get marked invalid and when they fire next time around with
the release with DERBY-1482 changes backed out, the regenerated sql
for them will be generated again and they will start behaving
correctly. So, it is *highly* recommended that the users upgrade
from 10.7.1.1 to next point release of 10.7 or to 10.8
Added:
db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_8.java (with props)
Modified:
db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeChange.java
db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeRun.java
Added: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_8.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_8.java?rev=1085613&view=auto
==============================================================================
--- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_8.java (added)
+++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_8.java Sat Mar 26 00:19:02 2011
@@ -0,0 +1,504 @@
+/*
+
+Derby - Class org.apache.derbyTesting.functionTests.tests.upgradeTests.Changes10_8
+
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+
+*/
+package org.apache.derbyTesting.functionTests.tests.upgradeTests;
+
+import org.apache.derbyTesting.junit.SupportFilesSetup;
+
+import java.sql.SQLException;
+import java.sql.SQLWarning;
+import java.sql.Statement;
+import java.sql.ResultSet;
+import java.util.HashSet;
+import java.util.Set;
+
+import junit.framework.Test;
+import junit.framework.TestSuite;
+
+import org.apache.derbyTesting.junit.JDBC;
+
+
+/**
+ * Upgrade test cases for 10.8.
+ * If the old version is 10.8 or later then these tests
+ * will not be run.
+ * <BR>
+ 10.8 Upgrade issues
+
+ <UL>
+ <LI>BOOLEAN data type support expanded.</LI>
+ </UL>
+
+ */
+public class Changes10_8 extends UpgradeChange
+{
+ ///////////////////////////////////////////////////////////////////////////////////
+ //
+ // CONSTANTS
+ //
+ ///////////////////////////////////////////////////////////////////////////////////
+
+ ///////////////////////////////////////////////////////////////////////////////////
+ //
+ // STATE
+ //
+ ///////////////////////////////////////////////////////////////////////////////////
+
+ ///////////////////////////////////////////////////////////////////////////////////
+ //
+ // CONSTRUCTOR
+ //
+ ///////////////////////////////////////////////////////////////////////////////////
+
+ public Changes10_8(String name)
+ {
+ super(name);
+ }
+
+ ///////////////////////////////////////////////////////////////////////////////////
+ //
+ // JUnit BEHAVIOR
+ //
+ ///////////////////////////////////////////////////////////////////////////////////
+
+ /**
+ * Return the suite of tests to test the changes made in 10.8.
+ * @param phase an integer that indicates the current phase in
+ * the upgrade test.
+ * @return the test suite created.
+ */
+ public static Test suite(int phase) {
+ TestSuite suite = new TestSuite("Upgrade test for 10.8");
+
+ suite.addTestSuite(Changes10_8.class);
+ return new SupportFilesSetup((Test) suite);
+ }
+
+ ///////////////////////////////////////////////////////////////////////////////////
+ //
+ // TESTS
+ //
+ ///////////////////////////////////////////////////////////////////////////////////
+
+ /**
+ * Changes made for DERBY-1482 caused corruption which is being logged
+ * under DERBY-5121. The issue is that the generated trigger action
+ * sql could be looking for columns (by positions, not names) in
+ * incorrect positions. With DERBY-1482, trigger assumed that the
+ * runtime resultset that they will get will only have trigger columns
+ * and trigger action columns used through the REFERENCING column.
+ * That is an incorrect assumption because the resultset could have
+ * more columns if the triggering sql requires more columns. DERBY-1482
+ * changes are in 10.7 and higher codelines. Because of this bug, the
+ * changes for DERBY-1482 have been backed out from 10.7 and 10.8
+ * codelines so they now match 10.6 and earlier releases. This in
+ * other words means that the resultset presented to the trigger
+ * will have all the columns from the trigger table and the trigger
+ * action generated sql should look for the columns in the trigger
+ * table by their absolution column position in the trigger table.
+ * This disabling of code will make sure that all the future triggers
+ * get created correctly. The existing triggers at the time of
+ * upgrade (to the releases with DERBY-1482 backout changes in them)
+ * will get marked invalid and when they fire next time around,
+ * the regenerated sql for them will be generated again and they
+ * will start behaving correctly. So, it is highly recommended that
+ * we upgrade 10.7.1.1 to next point release of 10.7 or to 10.8
+ * @throws Exception
+ */
+ public void testDERBY5121TriggerDataCorruption() throws Exception
+ {
+ Statement s = createStatement();
+ ResultSet rs;
+ boolean modeDb2SqlOptional = oldAtLeast(10, 3);
+
+ switch ( getPhase() )
+ {
+ case PH_CREATE: // create with old version
+ //The following test case is for testing in different upgrade
+ // phases what happens to buggy trigger created with 10.7.1.1.
+ // Such triggers will get fixed
+ // 1)in hard upgrade when they get fired next time around.
+ // 2)in soft upgrade if they get fired during soft upgrade session.
+ //For all the other releases, we do not generate buggy triggers
+ // and hence everything should work just fine during all phases
+ // of upgrade including the CREATE time
+ s.execute("CREATE TABLE UPGRADE_tab1(id int, name varchar(20))");
+ s.execute("CREATE TABLE UPGRADE_tab2(" +
+ "name varchar(20) not null, " +
+ "description int not null, id int)");
+ s.execute("create trigger UPGRADE_Trg1 " +
+ "after UPDATE of name on UPGRADE_tab2 " +
+ "referencing new as nr for each ROW "+
+ (modeDb2SqlOptional?"":"MODE DB2SQL ") +
+ "insert into UPGRADE_tab1 values ( nr.id, nr.name )");
+ //load data into trigger table
+ s.execute("insert into UPGRADE_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update UPGRADE_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from UPGRADE_tab1");
+ //If we are testing 10.7.1.1, which is where DERBY-5121 was
+ // detected, we will find that the trigger did not insert
+ // the correct data thus causing the corruption. For all the
+ // earlier releases, we do not have DERBY-5121 and hence
+ // trigger will insert the correct data.
+ if (oldIs(10,7,1,1))
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{"1","Another name"}});
+ else
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from UPGRADE_tab1");
+ s.execute("delete from UPGRADE_tab2");
+
+ //Following test is to test that the buggy triggers created in
+ // 10.7.1.1 will continue to exhibit incorrect behavior if they
+ // do not get fired during soft upgrade and the database is taken
+ // back to 10.7.1.1
+ s.execute("CREATE TABLE POSTSFT_UPGRD_tab1(id int, name varchar(20))");
+ s.execute("CREATE TABLE POSTSFT_UPGRD_tab2(" +
+ "name varchar(20) not null, " +
+ "description int not null, id int)");
+ //We want this trigger to fire only for post hard upgrade
+ s.execute("create trigger POSTSFT_UPGRD_Trg1 " +
+ "after UPDATE of name on POSTSFT_UPGRD_tab2 " +
+ "referencing new as nr for each ROW "+
+ (modeDb2SqlOptional?"":"MODE DB2SQL ") +
+ "insert into POSTSFT_UPGRD_tab1 values ( nr.id, nr.name )");
+ //load data into trigger table
+ s.execute("insert into POSTSFT_UPGRD_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update POSTSFT_UPGRD_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from POSTSFT_UPGRD_tab1");
+ //If we are testing 10.7.1.1, which is where DERBY-5121 was
+ // detected, we will find that the trigger did not insert
+ // the correct data thus causing the corruption. For all the
+ // earlier releases, we do not have DERBY-5121 and hence
+ // trigger will insert the correct data.
+ if (oldIs(10,7,1,1))
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{"1","Another name"}});
+ else
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from POSTSFT_UPGRD_tab1");
+ s.execute("delete from POSTSFT_UPGRD_tab2");
+
+ //Following test is to test that the buggy triggers created in
+ // 10.7.1.1 will get fixed when they get upgraded to 10.8 and
+ // higher
+ s.execute("CREATE TABLE HARD_UPGRADE_tab1(id int, name varchar(20))");
+ s.execute("CREATE TABLE HARD_UPGRADE_tab2(" +
+ "name varchar(20) not null, " +
+ "description int not null, id int)");
+ s.execute("create trigger HARD_UPGRADE_Trg1 " +
+ "after UPDATE of name on HARD_UPGRADE_tab2 " +
+ "referencing new as nr for each ROW "+
+ (modeDb2SqlOptional?"":"MODE DB2SQL ") +
+ "insert into HARD_UPGRADE_tab1 values ( nr.id, nr.name )");
+ //load data into trigger table
+ s.execute("insert into HARD_UPGRADE_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update HARD_UPGRADE_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from HARD_UPGRADE_tab1");
+ //If we are testing 10.7.1.1, which is where DERBY-5121 was
+ // detected, we will find that the trigger did not insert
+ // the correct data thus causing the corruption. For all the
+ // earlier releases, we do not have DERBY-5121 and hence
+ // trigger will insert the correct data.
+ if (oldIs(10,7,1,1))
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{"1","Another name"}});
+ else
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from HARD_UPGRADE_tab1");
+ s.execute("delete from HARD_UPGRADE_tab2");
+
+ //Following test is to test that the buggy triggers created in
+ // 10.7.1.1 will get fixed when they get upgraded to 10.8 and
+ // higher even if they did not get fired during the session which
+ // did the upgrade
+ s.execute("CREATE TABLE POSTHRD_UPGRD_tab1(id int, name varchar(20))");
+ s.execute("CREATE TABLE POSTHRD_UPGRD_tab2(" +
+ "name varchar(20) not null, " +
+ "description int not null, id int)");
+ //We want this trigger to fire only for post hard upgrade
+ s.execute("create trigger POSTHRD_UPGRD_Trg1 " +
+ "after UPDATE of name on POSTHRD_UPGRD_tab2 " +
+ "referencing new as nr for each ROW "+
+ (modeDb2SqlOptional?"":"MODE DB2SQL ") +
+ "insert into POSTHRD_UPGRD_tab1 values ( nr.id, nr.name )");
+ //load data into trigger table
+ s.execute("insert into POSTHRD_UPGRD_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update POSTHRD_UPGRD_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from POSTHRD_UPGRD_tab1");
+ //If we are testing 10.7.1.1, which is where DERBY-5121 was
+ // detected, we will find that the trigger did not insert
+ // the correct data thus causing the corruption. For all the
+ // earlier releases, we do not have DERBY-5121 and hence
+ // trigger will insert the correct data.
+ if (oldIs(10,7,1,1))
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{"1","Another name"}});
+ else
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from POSTHRD_UPGRD_tab1");
+ s.execute("delete from POSTHRD_UPGRD_tab2");
+ break;
+
+ case PH_SOFT_UPGRADE:
+ //Following test case shows that the buggy trigger created in
+ // 10.7.1.1 got fixed when it got fired in soft upgrade mode
+ //load data into trigger table
+ s.execute("insert into UPGRADE_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update UPGRADE_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from UPGRADE_tab1");
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from UPGRADE_tab1");
+ s.execute("delete from UPGRADE_tab2");
+ s.execute("drop trigger UPGRADE_Trg1");
+
+ //Following test case shows that the trigger created during
+ // soft upgrade mode behave correctly and will not exhibit
+ // the buggy behavior of 10.7.1.1
+ s.execute("create trigger UPGRADE_Trg1 " +
+ "after UPDATE of name on UPGRADE_tab2 " +
+ "referencing new as nr for each ROW "+
+ (modeDb2SqlOptional?"":"MODE DB2SQL ") +
+ "insert into UPGRADE_tab1 values ( nr.id, nr.name )");
+ //load data into trigger table
+ s.execute("insert into UPGRADE_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update UPGRADE_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from UPGRADE_tab1");
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from UPGRADE_tab1");
+ s.execute("delete from UPGRADE_tab2");
+ break;
+
+ case PH_POST_SOFT_UPGRADE:
+ //Following test shows that because the buggy trigger created in
+ // 10.7.1.1 was fired during the soft upgrade mode, it has gotten
+ // fixed and it will work correctly in all the releaes
+ //load data into trigger table
+ s.execute("insert into UPGRADE_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update UPGRADE_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from UPGRADE_tab1");
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from UPGRADE_tab1");
+ s.execute("delete from UPGRADE_tab2");
+ s.execute("drop trigger UPGRADE_Trg1");
+
+ //Following test case says that if we are back to 10.7.1.1 after
+ // soft upgrade, we will continue to create buggy triggers. The
+ // only solution to this problem is to upgrade to a release that
+ // fixes DERBY-5121
+ s.execute("create trigger UPGRADE_Trg1 " +
+ "after UPDATE of name on UPGRADE_tab2 " +
+ "referencing new as nr for each ROW "+
+ (modeDb2SqlOptional?"":"MODE DB2SQL ") +
+ "insert into UPGRADE_tab1 values ( nr.id, nr.name )");
+ //load data into trigger table
+ s.execute("insert into UPGRADE_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update UPGRADE_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from UPGRADE_tab1");
+ //If we are testing 10.7.1.1, which is where DERBY-5121 was
+ // detected, we will find that the trigger did not insert
+ // the correct data thus causing the corruption. For all the
+ // earlier releases, we do not have DERBY-5121 and hence
+ // trigger will insert the correct data.
+ if (oldIs(10,7,1,1))
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{"1","Another name"}});
+ else
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from UPGRADE_tab1");
+ s.execute("delete from UPGRADE_tab2");
+
+ //Following shows that the triggers that didn't get fired during
+ // soft upgrade will continue to exhibit incorrect behavior in
+ // 10.7.1.1. The only solution to this problem is to upgrade to a
+ // release that fixes DERBY-5121
+ //load data into trigger table
+ s.execute("insert into POSTSFT_UPGRD_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update POSTSFT_UPGRD_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from POSTSFT_UPGRD_tab1");
+ if (oldIs(10,7,1,1))
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{"1","Another name"}});
+ else
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from POSTSFT_UPGRD_tab1");
+ s.execute("delete from POSTSFT_UPGRD_tab2");
+
+ //Following shows that the triggers that didn't get fired during
+ // soft upgrade will continue to exhibit incorrect behavior in
+ // 10.7.1.1. The only solution to this problem is to upgrade to a
+ // release that fixes DERBY-5121
+ //load data into trigger table
+ s.execute("insert into HARD_UPGRADE_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update HARD_UPGRADE_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from HARD_UPGRADE_tab1");
+ if (oldIs(10,7,1,1))
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{"1","Another name"}});
+ else
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from HARD_UPGRADE_tab1");
+ s.execute("delete from HARD_UPGRADE_tab2");
+
+ //Following shows that the triggers that didn't get fired during
+ // soft upgrade will continue to exhibit incorrect behavior in
+ // 10.7.1.1. The only solution to this problem is to upgrade to a
+ // release that fixes DERBY-5121
+ //load data into trigger table
+ s.execute("insert into POSTHRD_UPGRD_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update POSTHRD_UPGRD_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from POSTHRD_UPGRD_tab1");
+ if (oldIs(10,7,1,1))
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{"1","Another name"}});
+ else
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from POSTHRD_UPGRD_tab1");
+ s.execute("delete from POSTHRD_UPGRD_tab2");
+ break;
+
+ case PH_HARD_UPGRADE:
+ //Following test shows that the buggy trigger created with 10.7.1.1
+ // will get fixed after hard upgrade. Following trigger was fired
+ // during soft upgrade and post soft upgrade
+ //load data into trigger table
+ s.execute("insert into UPGRADE_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update UPGRADE_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from UPGRADE_tab1");
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from UPGRADE_tab1");
+ s.execute("delete from UPGRADE_tab2");
+
+ //Following test shows that the buggy trigger created with 10.7.1.1
+ // will get fixed after hard upgrade. Following trigger was never
+ // fired in soft upgrade mode
+ //load data into trigger table
+ s.execute("insert into HARD_UPGRADE_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update HARD_UPGRADE_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from HARD_UPGRADE_tab1");
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from HARD_UPGRADE_tab1");
+ s.execute("delete from HARD_UPGRADE_tab2");
+ break;
+
+ case PH_POST_HARD_UPGRADE:
+ //Following test shows that the buggy trigger created with 10.7.1.1
+ // will get fixed after hard upgrade. Following trigger was fired
+ // during soft upgrade and post soft upgrade & during hard upgrade
+ //load data into trigger table
+ //load data into trigger table
+ s.execute("insert into UPGRADE_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update UPGRADE_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from UPGRADE_tab1");
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from UPGRADE_tab1");
+ s.execute("delete from UPGRADE_tab2");
+
+ //Following test shows that the buggy trigger created with 10.7.1.1
+ // will get fixed after hard upgrade. Following trigger was never
+ // fired in soft upgrade mode but was fired during hard upgrade
+ //load data into trigger table
+ //load data into trigger table
+ s.execute("insert into HARD_UPGRADE_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update HARD_UPGRADE_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from HARD_UPGRADE_tab1");
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from HARD_UPGRADE_tab1");
+ s.execute("delete from HARD_UPGRADE_tab2");
+
+ //Following test shows that the buggy trigger created with 10.7.1.1
+ // will get fixed after hard upgrade. This is the first time this
+ // trigger got fired after it's creation in 10.7.1.1 CREATE mode
+ //load data into trigger table
+ //load data into trigger table
+ s.execute("insert into POSTHRD_UPGRD_tab2(name,description) "+
+ "values ( 'Foo1 Name', 0 )");
+ //Cause the trigger to fire
+ s.execute("update POSTHRD_UPGRD_tab2 " +
+ "set name = 'Another name' , description = 1");
+ rs = s.executeQuery("select * from POSTHRD_UPGRD_tab1");
+ JDBC.assertFullResultSet(rs,
+ new String[][]{{null,"Another name"}});
+ s.execute("delete from POSTHRD_UPGRD_tab1");
+ s.execute("delete from POSTHRD_UPGRD_tab2");
+ break;
+ }
+ }
+}
Propchange: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_8.java
------------------------------------------------------------------------------
svn:eol-style = native
Modified: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeChange.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeChange.java?rev=1085613&r1=1085612&r2=1085613&view=diff
==============================================================================
--- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeChange.java (original)
+++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeChange.java Sat Mar 26 00:19:02 2011
@@ -111,6 +111,22 @@ abstract class UpgradeChange extends Bas
}
/**
+ * Get the fixpack number of the old version being upgraded
+ * from.
+ */
+ final int getOldFixPack() {
+ return ((int[]) oldVersion.get())[2];
+ }
+
+ /**
+ * Get the point number of the old version being upgraded
+ * from.
+ */
+ final int getOldPoint() {
+ return ((int[]) oldVersion.get())[3];
+ }
+
+ /**
* Return true if the old version is equal to or more
* recent that the passed in major and minor version.
*/
@@ -139,6 +155,19 @@ abstract class UpgradeChange extends Bas
// Old version matches exactly. That is, not less than.
return false;
+ }
+
+ /**
+ * Return true if and only if the old version is equal to the
+ * passed major, minor, fixpack and point version
+ * specified version.
+ */
+ boolean oldIs(int requiredMajor, int requiredMinor,
+ int requiredFixpack, int requiredPoint) {
+ return (getOldMajor() == requiredMajor)
+ && (getOldMinor() == requiredMinor)
+ && (getOldFixPack() == requiredFixpack)
+ && (getOldPoint() == requiredPoint);
}
/**
Modified: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeRun.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeRun.java?rev=1085613&r1=1085612&r2=1085613&view=diff
==============================================================================
--- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeRun.java (original)
+++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeRun.java Sat Mar 26 00:19:02 2011
@@ -195,6 +195,8 @@ class UpgradeRun extends UpgradeClassLoa
suite.addTest(Changes10_6.suite(phase));
if (oldMinor < 7)
suite.addTest(Changes10_7.suite(phase));
+ if (oldMinor < 8)
+ suite.addTest(Changes10_8.suite(phase));
}
// Add DatabaseMetaData tests. Since metadata