thanks knut, definitely a good chunk of testing. Could you log a JIRA with
what you found to fail (just a test output is fine with me) and an
improvement request. Seems like we could improve the problem tests to
only run if the source db is at a specific level. Would be interesting
to do similar testing with even more back level db's.
On 8/7/2014 4:56 AM, Knut Anders Hatlen wrote:
Rick Hillegas <[email protected]> writes:
On 8/6/14 11:37 AM, mike matrigali wrote:
On 8/6/2014 10:48 AM, Rick Hillegas wrote:
On 8/4/14 7:17 AM, Rick Hillegas wrote:
Heads up: I expect to flunk 10.11.1.0 because of
https://issues.apache.org/jira/browse/DERBY-6683. I will hold off
building a new release candidate so that we'll have time to collect
other problems. In particular, I would like to see the results of the
full-spectrum platform tests. I expect to publish a new release
candidate on Wednesday. This should not affect the target release date.
Thanks,
-Rick
I am pushing back the second release candidate until at least tomorrow.
I want to see the nightly platform results after checking in the fix to
https://issues.apache.org/jira/browse/DERBY-6692. In addition, Knut is
running the regression tests on a database which was created with
10.10.2.0, in order to flush out other problems related to soft-upgrade.
Thanks,
-Rick
Once done, could knut post how he did this? Is there just a
property or is other hacking needed. I know most of the junit
tests run on a single db, and maybe that is all he is going after.
I believe that's his approach. He's running the tests in a directory
which already has a wombat database created by 10.10.2.0.
That's right. I was reusing some scripts that I had used when running
10.10.2.0 release tests earlier, and accidentally also reused the old
databases that were still lying around. That's how I tripped across
DERBY-6692.
Thanks,
-Rick
I dont know how to
deal with those that need their own separate db.
I don't know either. Most tests use system/wombat though, so I think it
gives pretty good coverage.
I reran suites.All on a soft-upgraded database with head of 10.11 +
Rick's patch for DERBY-6692.
Now all the self-deadlocks are gone. There are still 21 failures and 68
errors when you run the tests this way. As far as I can tell, all of the
failures and errors are expected. I saw the following classes of errors:
- Use of the WHEN clause in triggers (not supported unless you upgrade
the database)
- Use of deferred constraints (not supported unless you upgrade the
database)
- Use of identity columns (expected new behaviour, got old behaviour)
- Checks of meta-data and system tables which expected the new
SYSCS_PEEK_AT_IDENTITY procedure to exist
No alarming results, so we're good to go from this perspective.
Thanks,
