On 3/29/11 12:01 PM, Mamta Satoor wrote:
Hi Rick,
I am looking at
org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeRun:baseSuite
and see following comment
* Changes are only added if the old version is older than
* then version the changes represent. Thus Changes10_2
* is not added if the old database (upgrade from) is already
* at 10.2, since Changes10_2 is intended to test upgrade
* from an older version to 10.2.
and part of the code in that method is as follows
if (phase != UpgradeChange.PH_POST_HARD_UPGRADE)
{
suite.addTest(BasicSetup.suite());
if (oldMajor == 10) {
if (oldMinor< 1)
suite.addTest(Changes10_1.suite());
if (oldMinor< 2)
suite.addTest(Changes10_2.suite());
if (oldMinor< 3) {
//Pass the phase as a parameter to the
//suite method that will enable the test to add existing
//junit tests after checking for the phase of the current
//run.
suite.addTest(Changes10_3.suite(phase));
}
if (oldMinor< 4)
suite.addTest(Changes10_4.suite(phase));
if (oldMinor< 5)
suite.addTest(Changes10_5.suite(phase));
if (oldMinor< 6)
suite.addTest(Changes10_6.suite(phase));
if (oldMinor< 7)
suite.addTest(Changes10_7.suite(phase));
}
If I am reading this right, then it sounds like if I am in current
10.7 codeline and add 10.7.1.1 to OldVersions.VERSIONS, even then we
will not be adding
suite.addTest(Changes10_7.suite(phase));
because the old minor version is not less than 7.
Hi Mamta,
I think that's correct if you want to put your new test cases into
Changes10_7. I think you can workaround this by putting your changes
into a new Changes10_7_2 class and then include Changes10_7_2 based on
looking at the third number in the release id as well as the first two
numbers. Hope that works.
Regards,
-Rick
Am I reading the
code correct? My upgrade test should go in Changes10_7.suite because I
want to specifically test upgrade from 10.7.1.1 to the next release of
10.7 to make sure that at the time of upgrade, triggers will get
fixed.
thanks,
Mamta
On Tue, Mar 29, 2011 at 5:41 AM, Rick Hillegas<[email protected]> wrote:
On 3/28/11 8:19 PM, Mamta Satoor wrote:
Hi,
For DERBY-5121 fix, the 10.7.1.1 users need to make sure that their
database gets upgraded to next Derby release with DERBY-1482 changes
backed out. As part of the upgrade to that release, the trigger action
SPSes will get marked invalid and when they get fired next time
around, correct trigger action SPSes will be generated for them,
To test the upgrade from 10.7.1.1 to trunk, I have already added a set
of upgrade tests with revision 1085613. It will be great if we did
similar testing for upgrade from 10.7.1.1 to the next point releases
of 10.7 to make sure that the trigger SPSes do get fixed. But if I
understand the upgrade test framework correctly, upgrade testing is
always from previous releases. I do not think there is a way to test
upgrade within point releases of the same codeline. Am I correct about
this? I haven't thought enough about it yet, but does anyone have any
ideas on what it might take to do the upgrade testing within point
releases?
Hi Mamta,
I wasn't aware of this limitation in the upgrade tests. I thought that they
just tested every hard and soft upgrade trajectory ending at the current
level of the codeline and starting at each of the previous releases listed
in OldVersions.VERSIONS (which can be overridden by the
-DderbyTesting.oldVersionsPath property). I don't know that we've ever tried
upgrade on a branch though. I don't think anyone updates OldVersion.VERSIONS
on a branch. I think we only bother to update it on the trunk.
Thanks,
-Rick
thanks,
Mamta
