[
https://issues.apache.org/jira/browse/DERBY-5866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854398#comment-13854398
]
Knut Anders Hatlen commented on DERBY-5866:
-------------------------------------------
I don't think there will be any need to update existing timestamps for
correctness. If the change from local time zone to UTC makes the old timestamps
appear to be in the future, the current logic will adjust the timestamp of the
new trigger to point even further into the future.
It is of course unfortunate that the timestamps of existing triggers won't
represent the actual creation time anymore, but I have a hard time imagining
that application logic would depend on these timestamps. it's probably worth
mentioning in a release note, and also having a cautionary note in the
SYSTRIGGERS topic in the reference manual.
I'm a little bit worried about downgrade, though. Switching back from UTC to
local may give Derby the impression that time travel has happened, and old
versions don't have the logic we've added here to compensate for time travel.
So maybe we should only switch to UTC if the database has been hard-upgraded.
>
> 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,
> 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.4#6159)
