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