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] [Commented] (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, 12 Dec 2013 13:47:07 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13846308#comment-13846308
] 

Knut Anders Hatlen commented on DERBY-5866:
-------------------------------------------

If we only care about the case where two timestamps are identical because the system clock
is too coarse-grained, the fix should be rather simple. We could just make CreateTriggerConstantAction
cache the latest creation timestamp (for example in a field in DataDictionaryImpl) and add
1 nanosecond if a collision is detected.

But there are more cases to consider if we want to solve the general problem:

- What if a database is copied from one computer to another, and their clocks are not synchronized?

- What if a trigger is created during the last hour of daylight saving time? Since Derby doesn't
store the time zone of a timestamp, a new trigger created within the next hour may appear
to have been created before the first trigger.

- Similar case: What if the time zone on the computer is changed so that the old timestamps
appear to be newer than they actually are?

I suppose we could solve this by making the first CREATE TRIGGER statement after boot fetch
the highest CREATIONTIMESTAMP from SYSTRIGGERS for comparison with new timestamps, and if
the new timestamp is lower than the highest one in SYSTRIGGERS, create a new timestamp that
points far enough into the future. It won't be pretty though, and we'll have to pay attention
to corner cases, especially around DST switchover.

I guess what we'd really want, is SYSTRIGGERS to have an identity column so that we could
have a monotonically increasing value independent of the system clock, but that requires format
changes in hard upgrade. Still, it sounds much cleaner to implement a sequence number using
an identity column, than faking it with a data type where you don't even know if incrementing
a value by one will result in a smaller or bigger value than the original...

>  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
>             Fix For: 10.8.3.1, 10.9.2.2, 10.10.1.3, 10.11.0.0
>
>         Attachments: error-stacktrace.out, fail1.zip, fail2.zip
>
>
> 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)

Mime
View raw message