[
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-ab-newtest.diff
Attaching a new version of this test: derby-4157-02-ab-newtest.diff. This
changes the test so that, by default, it only runs a minimal set of
trajectories, viz., just those which begin with some release and then upgrade
through ALL intermediate releases up to the highest release. On a set of N
releases, this gives rise to only N-1 trajectories, rather than the daunting
((2**N) - N) - 1 trajectories in the full test. I think that this minimal
default has some value. It would have caught the problem logged in DERBY-4214.
However, it would not have caught the problem logged in DERBY-4215.
With the small memory settings in the previous experiment, I ran out of memory
running the full test. I increased the memory to 1G for perm gen space and 1G
for heap. With that setting I was able to run for a half hour without running
out of memory--then I killed the test. That may be good enough. Or it may not
be. This is the new command line to run the full test:
java -XX:MaxPermSize=1024m -Xmx1024m \
-DderbyTesting.allTrajectories=true \
-DderbyTesting.oldReleasePath=/Users/me/myDerbyReleaseDirectory \
-DderbyTesting.oldVersionsPath=/Users/me/fileContainingMyListOfTastyReleases \
junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTrajectoryTest
I miscalculated how long it would take to run the full test against all upgrade
trajectories which are possible on my set of releases. My 14 releases give rise
to 16369 trajectories. I was finding that the long trajectories were taking
about 10 seconds apiece to evaluate. That's about 19 days for the whole set.
Needless to say, I am not going to run this sequence on my humble machine. If
you need to run a particular trajectory, you can hand-edit the
makeSampleTrajectories() method and uncomment the call to it.
Here's the command line to run this test against the default (minimal) set of
trajectories:
java -XX:MaxPermSize=1024m -Xmx1024m \
-DderbyTesting.oldReleasePath=/Users/me/myDerbyReleaseDirectory \
-DderbyTesting.oldVersionsPath=/Users/me/fileContainingMyListOfTastyReleases \
junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTrajectoryTest
This test is not wired into the regression test suite. You have to run it
standalone. As a sanity check I ran the full regression suite successfully.
Committed at subversion revision 785826.
> 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
> Assignee: Rick Hillegas
> Attachments: derby-4157-01-aa-refactor.diff,
> derby-4157-02-aa-newtest.diff, derby-4157-02-ab-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.
