[jira] Updated: (DERBY-4157) Create a test to verify that virgin metadata is identical to hard-upgraded metadata

["Rick Hillegas (JIRA)" <ji...@apache.org>]

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