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, -- Knut Anders
