Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <228727477.1241720565630.JavaMail.jira@brutus>
Date: Thu, 7 May 2009 11:22:45 -0700 (PDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-4157) Create a test to verify that virgin
 metadata is identical to hard-upgraded metadata
In-Reply-To: <835401922.1239387915046.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Hillegas updated DERBY-4157:
---------------------------------

    Attachment: derby-4157-02-aa-newtest.diff

Attaching derby-4157-02-aa-newtest.diff. This introduces a new test for exercising all upgrade trajectories and verifying that the metadata in freshly created databases is the same as the metadata in pre-existing databases which are hard-upgraded. As currently configured, the test only verifies hard-upgrade trajectories. However, the test can be changed to test arbitrary mixes of hard and soft upgrade also.

The test has been run on all non-vacuous hard-upgrade trajectories that are possible given the following set of releases:

    10.0.2.1
    10.1.3.1
    10.2.2.1
    10.3.3.0
    10.4.2.1
    10.5.1.1

Bugs have been logged already for the metadata discrepancies which turned up on those trajectories. The test skips over those known discrepancies. That is, if you run the test against that set of versions, you will get a clean run.

---------------------

The following description recaps the header comment in the test:

Test all upgrade trajectories. This test compares the metadata in upgraded databases to the metadata in databases created from scratch. Given a collection of releases, this test does the following:

* Builds the set of all upgrade trajectories possible on that collection of releases. An upgrade trajectory is a sorted subset of those releases. Each subset is sorted in ascending release order. We exclude the vacuous empty subset and the uninteresting singleton subsets. A set of N releases gives rise to ((2**N) - N) - 1 hard-upgrade trajectories.

* For each trajectory, we create two databases:

  o A starting point database created with the first release in the trajectory. This database is then upgraded through all of the intermediate releases in the trajectory until it is at the level of the last release in the trajectory.
  o An ending point database created with the last release in the trajectory.

* We then compare the metadata in the starting point and ending point databases.

By default we don't consider soft-upgrades. Also by default, we consider trajectories with more than one release from the same branch. You can parameterize or customize some constants (see below) if you want to change these decisions.

By default we consider all trajectories possible on the collection of releases listed in _Suite. If you want to consider a different collection of releases, you can override the _Suite collection by setting the system property "derbyTesting.oldVersionsPath". Here, for instance, is the command line to run this test against a customized list of releases:

     java -XX:MaxPermSize=128M -Xmx512m \
     -DderbyTesting.oldReleasePath=/Users/me/myDerbyReleaseDirectory \
     -DderbyTesting.oldVersionsPath=/Users/me/fileContainingMyListOfTastyReleases \
     junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTrajectoryTest

For extra verbose output, you can set the "derby.tests.debug" property too:

     java -XX:MaxPermSize=128M -Xmx512m \
     -DderbyTesting.oldReleasePath=/Users/me/myDerbyReleaseDirectory \
     -DderbyTesting.oldVersionsPath=/Users/me/fileContainingMyListOfTastyReleases \
     -Dderby.tests.debug=true \
     junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTrajectoryTest

---------------------

My next step will be to run the test against all hard-upgrade trajectories possible on the full set of 14 releases that I have on my machine. I think this will take about 10 hours.

    10.0.2.1
    10.1.1.0
    10.1.2.1
    10.1.3.1
    10.2.1.6
    10.2.2.0
    10.2.2.1
    10.3.1.4
    10.3.2.1
    10.3.3.0
    10.4.1.3
    10.4.2.0
    10.4.2.1
    10.5.1.1

---------------------

This patch consists of the following files:

M      java/engine/org/apache/derby/iapi/services/info/ProductVersionHolder.java

Made a constant public so that I could use it to decode version numbers.


A      java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Version.java

This new class encapsulates the behavior of Versions and Trajectories.


A      java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeTrajectoryTest.java

This is the actual test. Each trajectory is a separate test case.


> Create a test to verify that virgin metadata is identical to hard-upgraded metadata
> -----------------------------------------------------------------------------------
>
>                 Key: DERBY-4157
>                 URL: https://issues.apache.org/jira/browse/DERBY-4157
>             Project: Derby
>          Issue Type: Test
>          Components: Test
>    Affects Versions: 10.6.0.0
>            Reporter: Rick Hillegas
>         Attachments: derby-4157-01-aa-refactor.diff, derby-4157-02-aa-newtest.diff
>
>
> We should write a test to verify that the metadata is correct for each release for all hard-upgrade trajectories which terminate in that release. The test should examine all system tables. Note that if there are N releases, then there will (2<sup>N</sup> - N) - 1 trajectories to examine.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.