db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5866) testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)junit.framework.AssertionFailedError: matching triggers need to be fired in order creation:1,NO CASCADE BEFORE,DELETE,ROW
Date Thu, 02 Jan 2014 14:35:50 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Knut Anders Hatlen updated DERBY-5866:
--------------------------------------

    Attachment: d5866-2b-utc-after-upgrade.diff

Uploading d5866-2b-utc-after-upgrade.diff which replaces the 2a patch. The new patch only
uses UTC for the creation timestamps if the database has been upgraded to 10.11. That is,
soft-upgraded databases will still use the local time zone.

It also adds a test case to the upgrade test suite which verifies that triggers created in
different phases of the upgrade fire in the correct order. With the 2a patch, this test case
failed because the trigger created in a soft-downgraded database would fire out of order (only
if the local time zone in which the test ran had a negative offset from GMT, though, since
then the switch from UTC back to local time zone would look like travel back in time). The
2b patch makes the test case pass by using UTC only after hard-upgrade, in which case the
database cannot be soft-downgraded to a version that uses the local time zone.

I considered whether there should be upgrade code that changed timestamps for existing triggers
from local time zone to UTC, but chose not to add it because

- it's not needed for correct trigger execution order
- one cannot determine at upgrade time what the local time zone was at the time the trigger
was created (although the current local time zone would be a reasonable guess)
- because of ambiguities around switch to or from DST, conversion to UTC could end up reordering
the triggers, and we wouldn't want upgrade to alter the execution order of existing triggers

I think the 1a patch can be backported to older branches (which means the older branches would
behave like trunk in soft-upgrade, and the tests instabilities should go away), whereas the
2b patch should only go to trunk because of its hard-upgrade impact.

>  testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)junit.framework.AssertionFailedError:
matching triggers need to be fired in order creation:1,NO CASCADE BEFORE,DELETE,ROW
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5866
>                 URL: https://issues.apache.org/jira/browse/DERBY-5866
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.10.1.1, 10.10.1.3
>         Environment: Windows IBM 1.6 10.10.0.0 alpha - (1361856)
>            Reporter: Kathey Marsden
>            Assignee: Knut Anders Hatlen
>              Labels: derby_triage10_11
>         Attachments: d5866-1a-adjust-timestamp.diff, d5866-2a-utc.diff, d5866-2b-utc-after-upgrade.diff,
error-stacktrace.out, fail1.zip, fail2.zip, time-zone-test.diff
>
>
> I saw this failure in the IBM nightlies on 7/15. The subsequent night did not fail, so
appears intermittent
> http://cloudsoft.usca.ibm.com/intranet/nightlies/derbywinvm/JarResults.2012-07-15/ibm16_suites.All/suites.All.out
> 1) testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)junit.framework.AssertionFailedError:
matching triggers need to be fired in order creation:1,NO CASCADE BEFORE,DELETE,ROW
> 	at org.apache.derbyTesting.functionTests.tests.lang.TriggerTest.assertFiringOrder(TriggerTest.java:560)
> 	at org.apache.derbyTesting.functionTests.tests.lang.TriggerTest.testFiringConstraintOrder(TriggerTest.java:500)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
> 	at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424)
> 	at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message