You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2014/01/02 15:35:50 UTC
[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
[ 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)