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 to the next point release of 10.7 codeline
Date Tue, 29 Mar 2011 19:01:49 GMT
Hi Rick,

I am looking at
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)

            if (oldMajor == 10) {
                if (oldMinor < 1)
                if (oldMinor < 2)
                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
                if (oldMinor < 4)
                if (oldMinor < 5)
                if (oldMinor < 6)
                if (oldMinor < 7)

If I am reading this right, then it sounds like if I am in current
10.7 codeline and add to OldVersions.VERSIONS, even then we
will not be adding
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 to the next release of
10.7 to make sure that at the time of upgrade, triggers will get


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 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 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 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

View raw message