db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mike matrigali <mikema...@gmail.com>
Subject Re: problems with the 10.11.1.0 release candidate
Date Thu, 07 Aug 2014 17:04:17 GMT
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 <rick.hillegas@oracle.com> 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,
>


Mime
View raw message