db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: problems with the 10.11.1.0 release candidate
Date Thu, 07 Aug 2014 11:56:06 GMT
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,

-- 
Knut Anders

Mime
View raw message