db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.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 20:04:52 GMT
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<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