Hi Bryan, I've edited the large inline comments in the latest patch. And added a few more tests.
I thought about it and I think the test cases can be divided on the number of columns being referenced by trigger and the number of columns being referenced by the update clause. I tested quite a few queries and apparently the when clause always evaluates correctly, provided correct columns are being accessed. So the new test cases basically check different combinations of trigger and update columns. It also cover all the basic data types. For breaking Derby-6783 into smaller sub-tasks, I think maybe we can use the number of referenced columns in the trigger as a basis, since the changes we made seem to solve the bug when only one column trigger is created. And we will have a mostly a resolved bug and an unresolved bug for multiple columns in trigger. On Wed, Jun 17, 2015 at 7:37 PM, Abhinav Gupta <[email protected]> wrote: > Hi Bryan, > > Another thing that I noticed, I forgot to mention it in the mail I just > sent. > The query does not run successfully if it has a trigger on more than one > field. > > As in AFTER UPDATE OF FIELD1 , works while a query like AFTER UPDATE OF > FIELD1, FIELD2 , does not. > > On Wed, Jun 17, 2015 at 7:32 PM, Abhinav Gupta <[email protected] > > wrote: > >> >> >>> At first I thought "CHAR '20'" meant a character string of length 20, but >>> then I looked again at the funny way that '20' was written, and perhaps >>> it is the hex representation of an ASCII space character which has the >>> character code 0x20. >> >> >> I'm quite certain that '20' is arising from the value I had put in the >> query, because if I change the value of the field marks1 in the test query, >> the error changes to "CHAR '30'" which is the case with the latest patch >> I've added. >> >> >
