db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-5121) Data corruption when executing an UPDATE trigger
Date Tue, 15 Mar 2011 17:27:29 GMT

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

Mamta A. Satoor commented on DERBY-5121:
----------------------------------------

This data corruption regression is in 10.8 and 10.7 codelines.

I should have a patch for review soon today which will disable the column reading optimization
and hence any newly created triggers will work fine. There will be still be issues with triggers
already created. This can be a problem with 10.7 since we may already have customers using
that release. Fortunately, 10.8 is not out yet to impact any customers. For 10.7, the users
will have to drop and recreate their triggers(only the triggers which are defined at row level
and which use REFERENCING clause. All the other triggers will work fine).

Once we have the patch reviewed and committed, I would like to see how I can do the selective
column reading and correct column mapping to the resultset at runtime. With the buggy 10.7
and 10.8 code, at the create trigger time, I do the column mapping for the trigger action
columns making the assumptions that those columns are the only columns which will exist in
the runtime resultset. That assumption is incorrect as shown in the test cases attached to
this jira. I am thinking of pursuing the solution where the trigger action sql should not
be generated at the create trigger time. Instead, it should be generated when the trigger
gets fired and the column position mapping of trigger action columns should happen based on
what columns exist in what positions in the runtime resultset. Please let me know if anyone
sees a problem with this approach. Any existing generated trigger action sql for existing
triggers will be disregarded and it will be just generated at the trigger firing time. This
approach will take care of the existing triggers and the new triggers. Once we have this fix
in, the 10.7 users will not have to drop and recreate their triggers.

> Data corruption when executing an UPDATE trigger
> ------------------------------------------------
>
>                 Key: DERBY-5121
>                 URL: https://issues.apache.org/jira/browse/DERBY-5121
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.7.1.1, 10.8.0.0
>            Reporter: Rick Hillegas
>            Assignee: Mamta A. Satoor
>              Labels: derby_triage10_8
>         Attachments: DummyProc.java, triggerBug.sql, triggerBug.sql, triggeredBug2.sql,
triggeredCorruption.sql
>
>
> When executing an UPDATE trigger, the following error is raised. I will attach a test
case:
> ERROR XCL12: An attempt was made to put a data value of type 'org.apache.derby.impl.jdbc.EmbedClob'
into a data value of type 'INTEGER'.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message