db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mamta Satoor <msat...@gmail.com>
Subject Re: DERBY-5121 and testing upgrade from 10.7.1.1 to the next point release of 10.7 codeline
Date Tue, 29 Mar 2011 19:01:49 GMT
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. 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 <rick.hillegas@oracle.com> 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
>>
>
>

Mime
View raw message