db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ma...@apache.org
Subject svn commit: r1133495 - in /db/derby/code/branches/10.7: ./ java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/
Date Wed, 08 Jun 2011 18:11:22 GMT
Author: mamta
Date: Wed Jun  8 18:11:22 2011
New Revision: 1133495

URL: http://svn.apache.org/viewvc?rev=1133495&view=rev
Log:
Backporting revision 1132664 from trunk to 10.8 codeline. In addition to the backport, had
to make couple changes by hand. Added 10.7.1.1 to the list of old revisions of Derby from
which there will be upgrade to current 10.7 codeline. The reason for adding 10.7.1.1 is DERBY-5121
which caused data corruption is this release. This was fixed in the 10.7 codeline after 10.7.1.1
and we want to make sure that the faulty triggers created in 10.7.1.1 get fixed when taken
to 10.7 codeline. 

Also, normally, when an older release is hard upgraded to the codeline, the database can't
be booted again with the old release. But when we are testing upgrade from 10.7.1.1 to current
codeline on 10.7, we can always goback to 10.7.1.1 because it is simply a point release upgrade.
I have changed the upgrade test to allow this going back to 10.7.1.1 after the db has been
hard upgraded to 10.7 codeline.

Commit comments for 1132664
Giving the upgrade tests in Changes10_8 a little more thought, I feel that the more appropriate
place for the tests will be in upgradeTests.BasicSetup. The reason for this is that the tests
are creating triggers and testing the results when they get fired. This kind of testing is
not unique to any particular Derby release and hence it is better for them to go in BasicSetup
to make sure that the results are consistent between various phases of upgrades. We do already
know that because of the bug DERBY-5121, the results will be incorrect in 10.7.1.1 and the
test is verifying those incorrect reulsts for 10.7.1.1. Based on this, I am putting these
set of trigger tests in BasicSetup.java This makes Changes10_8.java to have no tests left
in it and hence we can delete Changes10_8.java from svn.


Modified:
    db/derby/code/branches/10.7/   (props changed)
    db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/BasicSetup.java
    db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/OldVersions.java
    db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeChange.java

Propchange: db/derby/code/branches/10.7/
------------------------------------------------------------------------------
--- svn:mergeinfo (original)
+++ svn:mergeinfo Wed Jun  8 18:11:22 2011
@@ -1 +1 @@
-/db/derby/code/trunk:1035603,1036769,1038514,1038813,1039084,1039268,1040658,1041338,1043227,1043389,1044096,1051026,1053724,1055169,1059888,1060480,1062096,1063809,1065061,1066290,1067250,1067357,1069661,1071463,1071886,1076387,1078461,1078693,1081455,1081568,1085078,1091000,1097247,1103681,1103718,1129136,1130632,1130895,1131272
+/db/derby/code/trunk:1035603,1036769,1038514,1038813,1039084,1039268,1040658,1041338,1043227,1043389,1044096,1051026,1053724,1055169,1059888,1060480,1062096,1063809,1065061,1066290,1067250,1067357,1069661,1071463,1071886,1076387,1078461,1078693,1081455,1081568,1085078,1091000,1097247,1103681,1103718,1129136,1130632,1130895,1131272,1132664

Modified: db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/BasicSetup.java
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/BasicSetup.java?rev=1133495&r1=1133494&r2=1133495&view=diff
==============================================================================
--- db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/BasicSetup.java
(original)
+++ db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/BasicSetup.java
Wed Jun  8 18:11:22 2011
@@ -230,9 +230,15 @@ public class BasicSetup extends UpgradeC
      */
     public void noConnectionAfterHardUpgrade()
     {              
-        switch (getPhase())
-        {
-        case PH_POST_HARD_UPGRADE:
+    	//If oldIs 10.7, then we are testing upgrade between two
+    	//releases of 10.7. In such a case, even after hard upgrade,
+    	//we will be able to go back to the previous release of 10.7
+    	if (oldIs(10,7))
+    		return;
+    	
+    	switch (getPhase())
+    	{
+	        case PH_POST_HARD_UPGRADE:
             try {
                     getConnection();
                 } catch (SQLException e) {
@@ -300,6 +306,477 @@ public class BasicSetup extends UpgradeC
         }
 
     }
+
+    public void testDERBY5121TriggerTest2() throws Exception
+    {
+        Statement s = createStatement();
+        boolean modeDb2SqlOptional = oldAtLeast(10, 3);
+    	String updateSQL = "update media "+
+    	"set name = 'Mon Liza', description = 'Something snarky.' " +
+    	"where mediaID = 1";
+        
+        switch ( getPhase() )
+        {
+        case PH_CREATE: // create with old version
+        	s.execute("create table folder ( "+
+        			"folderType	int	not null, folderID	int	not null, "+
+        			"folderParent int, folderName varchar(50) not null)");
+        	s.execute("create table media ( " +
+        			"mediaID int not null, name varchar(50)	not null, "+
+        			"description clob not null, mediaType varchar(50), "+
+        			"mediaContents	blob, folderID int not null	default 7)");
+        	s.execute("create trigger mediaInsrtDupTrgr " +
+        			"after INSERT on media referencing new as nr "+
+        			"for each ROW "+
+        			(modeDb2SqlOptional?"":"MODE DB2SQL ") +
+        			"values( nr.folderID, 7, nr.name)");
+        	s.execute("create trigger mediaUpdtDupTrgr " +
+        			"after UPDATE of folderID, name on media " +
+        			"referencing new as nr "+
+        			"for each ROW "+
+        			(modeDb2SqlOptional?"":"MODE DB2SQL ") +
+        			"values( nr.folderID, 7, nr.name)");
+        	s.executeUpdate("insert into folder(folderType, folderID, "+
+        			"folderParent, folderName ) "+
+        			"values ( 7, 7, null, 'media' )");
+        	s.executeUpdate("insert into media(mediaID, name, description)"+
+        			"values (1, 'Mona Lisa', 'A photo of the Mona Lisa')");
+        	if (oldIs(10,7,1,1))
+                assertStatementError(  "XCL12", s, updateSQL );
+        	else
+        		s.executeUpdate(updateSQL);
+        	break;
+
+        case PH_SOFT_UPGRADE:
+    		s.executeUpdate(updateSQL);
+        	break;
+        	
+        case PH_POST_SOFT_UPGRADE:
+        	//Derby 10.7.1.1 is not going to work because UPDATE sql should
+        	// have read all the columns from the trigger table but it did
+        	// not and hence trigger can't find the column it needs from the
+        	// trigger table
+        	if (oldIs(10,7,1,1))
+                assertStatementError(  "S0022", s, updateSQL );
+        	else
+        		s.executeUpdate(updateSQL);
+        	break;
+        case PH_HARD_UPGRADE:
+    		s.executeUpdate(updateSQL);
+        	break;
+        case PH_POST_HARD_UPGRADE:
+    		s.executeUpdate(updateSQL);
+        	s.executeUpdate("drop table media");
+        	s.executeUpdate("drop table folder");
+        	break;
+        }
+    }
+
+    /**
+     * 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;
+        }
+    }
+
     final   int TEST_COUNT = 0;
     final   int FAILURES = TEST_COUNT + 1;
     final   String  A_COL = "a";

Modified: db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/OldVersions.java
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/OldVersions.java?rev=1133495&r1=1133494&r2=1133495&view=diff
==============================================================================
--- db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/OldVersions.java
(original)
+++ db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/OldVersions.java
Wed Jun  8 18:11:22 2011
@@ -51,6 +51,13 @@ public class OldVersions
         {10, 5, 3, 0}, // 10.5.3.0 (August 21, 2009 / SVN 802917)
         {10, 6, 1, 0}, // 10.6.1.0 (May 18, 2010/ SVN 938214)
         {10, 6, 2, 1}, // 10.6.2.1 (Oct 6, 2010/ SVN 999685
+        //Have added 10.7.1.1 here because DERBY-5121 which caused
+        // data corruption is in this release. This was fixed in 
+        // the 10.7 codeline after 10.7.1.1 and we want to make
+        // sure that the fault triggers created in 10.7.1.1 get
+        // fixed when taken to 10.7 codeline. These tests are
+        // part of BasicSetup.java
+        {10, 7, 1, 1}, // 10.7.1.1 (December 14, 2010/ SVN 1040133)
     };
 
     //Constant for special upgrade testing with both upgrade and create 

Modified: db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeChange.java
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeChange.java?rev=1133495&r1=1133494&r2=1133495&view=diff
==============================================================================
--- db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeChange.java
(original)
+++ db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeChange.java
Wed Jun  8 18:11:22 2011
@@ -111,6 +111,23 @@ 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.
      */
@@ -131,5 +148,18 @@ abstract class UpgradeChange extends Bas
     {
         return (getOldMajor() == requiredMajor)
           && (getOldMinor() == requiredMinor);
-     } 
+    }
+
+    /**
+     * 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);     
+    } 
 }



Mime
View raw message