You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Mamta Satoor <ms...@gmail.com> on 2011/03/29 05:19:07 UTC

DERBY-5121 and testing upgrade from 10.7.1.1 to the next point release of 10.7 codeline

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?

thanks,
Mamta

Re: Could someone please remove my e-mail from this distribution list?

Posted by William Eimer <wi...@yahoo.com>.
Hi Kristian,

I subscribed a few years back, but since have changed focus. I tried to 
unsubscribe in the past, but it did not work.

My subscribed email address is this one.. williameimer@yahoo.com.

Please unsubscribe me if you can.

(I deleted the most recent emails so I do not have one to forward at this time.)

Thanks,

Will




----- Original Message ----
From: Kristian Waagan <kr...@apache.org>
To: derby-dev@db.apache.org
Cc: William Eimer <wi...@yahoo.com>; adam.kosta@btinternet.com
Sent: Wed, March 30, 2011 3:33:57 PM
Subject: Re: Could someone please remove my e-mail from this distribution list?

On 30.03.11 20:02, William Eimer wrote:
> Please unsubscribe me too.

Will and Adam,

Can you forward a message you have received from the list (feel free to 
send it to me directly)? Please forward the complete message, including 
headers. I need it to verify which address you are subscribed with. I'll 
then try to unsubscribe you both from this end.
Also, are you getting a reply from the list manager when trying to 
unsubscribe?

I assume you have followed the instructions at 
http://db.apache.org/derby/derby_mail.html , posting the link for 
completeness. I believe you have to send the unsubscription request from 
the address you subscribed with.


Regards,
-- 
Kristian

> Thanks,
>
> williameimer@yahoo.com
>
> --- On Wed, 3/30/11, Adam Kosta<ad...@btinternet.com>  wrote:
>
>> From: Adam Kosta<ad...@btinternet.com>
>> Subject: Could someone please remove my e-mail from this distribution list?
>> To: derby-dev@db.apache.org
>> Date: Wednesday, March 30, 2011, 1:43 PM
>> I have tried countless times to
>> unsubscribe but no luck....
>>
>>
>>
>
>


      

Re: Could someone please remove my e-mail from this distribution list?

Posted by Kristian Waagan <kr...@apache.org>.
On 30.03.11 20:02, William Eimer wrote:
> Please unsubscribe me too.

Will and Adam,

Can you forward a message you have received from the list (feel free to 
send it to me directly)? Please forward the complete message, including 
headers. I need it to verify which address you are subscribed with. I'll 
then try to unsubscribe you both from this end.
Also, are you getting a reply from the list manager when trying to 
unsubscribe?

I assume you have followed the instructions at 
http://db.apache.org/derby/derby_mail.html , posting the link for 
completeness. I believe you have to send the unsubscription request from 
the address you subscribed with.


Regards,
-- 
Kristian

> Thanks,
>
> williameimer@yahoo.com
>
> --- On Wed, 3/30/11, Adam Kosta<ad...@btinternet.com>  wrote:
>
>> From: Adam Kosta<ad...@btinternet.com>
>> Subject: Could someone please remove my e-mail from this distribution list?
>> To: derby-dev@db.apache.org
>> Date: Wednesday, March 30, 2011, 1:43 PM
>> I have tried countless times to
>> unsubscribe but no luck....
>>
>>
>>
>
>


Re: Could someone please remove my e-mail from this distribution list?

Posted by William Eimer <wi...@yahoo.com>.
Please unsubscribe me too.

Thanks,

williameimer@yahoo.com

--- On Wed, 3/30/11, Adam Kosta <ad...@btinternet.com> wrote:

> From: Adam Kosta <ad...@btinternet.com>
> Subject: Could someone please remove my e-mail from this distribution list?
> To: derby-dev@db.apache.org
> Date: Wednesday, March 30, 2011, 1:43 PM
> I have tried countless times to
> unsubscribe but no luck....
> 
> 
> 


      

Could someone please remove my e-mail from this distribution list?

Posted by Adam Kosta <ad...@btinternet.com>.
I have tried countless times to unsubscribe but no luck....



Re: DERBY-5121 and testing upgrade from 10.7.1.1 to the next point release of 10.7 codeline

Posted by Rick Hillegas <ri...@oracle.com>.
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<ri...@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
>>>
>>


Re: DERBY-5121 and testing upgrade from 10.7.1.1 to the next point release of 10.7 codeline

Posted by Mamta Satoor <ms...@gmail.com>.
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 <ri...@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
>>
>
>

Re: DERBY-5121 and testing upgrade from 10.7.1.1 to the next point release of 10.7 codeline

Posted by Rick Hillegas <ri...@oracle.com>.
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
>