Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Thu, 12 Dec 2013 13:47:07 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12599463.1342705299462.23780.1386856027875@arcas>
In-Reply-To: <JIRA.12599463.1342705299462@arcas>
References: <JIRA.12599463.1342705299462@arcas>
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
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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)