db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4157) Create a test to verify that virgin metadata is identical to hard-upgraded metadata
Date Thu, 07 May 2009 18:22:45 GMT

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


Mime
View raw message