Hi Bryan,
I tried to refactor getTriggerActionString, the way you suggested. It still
doesn't solve the problem.
In my implementation, examineTriggerNodeAndCols returns a string with
column positions, so I've two strings one for action node and the other for
when node. And then I pass the respective strings to
getTriggerActionString().
I hope I've implemented it correctly.
Another thing that I noticed today was, in this loop that is a part of
getTriggerActionString
for (ColumnReference ref : refs)
{
TableName tableName = ref.getQualifiedTableName();
int tableBeginOffset =
tableName.getBeginOffset() - actionOffset;
I suppose this loop should work for Status and ID when it is called by the
action node and only for status when it is called by the when node. But
when I print out the value of columnReference, I notice that for action
node, I only get ID in my output though I was expecting both ID and Status.
And I get Status for when node, which I is what I expect.
On Wed, Jun 3, 2015 at 8:28 AM, Bryan Pendleton <[email protected]>
wrote:
> Hi Abhinav,
>
> I was able to build and run your sort code, and it seemed to be behaving
> as you expected it to, but the test case still seemed to be generating
> the wrong code, such that the "when" clause was accessing the value of
> the ID column instead of accessing the value of the STATUS column.)
>
> I feel like part of the problem is that the method
>
> DataDictionaryImpl.getTriggerActionString()
>
> is trying to do two different things:
>
> 1) It is computing the set of columns that are referenced by the parse node
>
> 2) And it is using that set of columns to generate the trigger action SQL
>
> I think that the source of the bug is that we FIRST need to do task (1)
> for both the trigger action node and the trigger when node, and THEN
> do task (2) for both the trigger action node and the trigger when node.
>
> But since the two tasks are bundled into a single routine, we end up
> doing them in this order:
>
> (1) (for the action node)
> (2) (for the action node)
> (1) (for the WHEN clause)
> (2) (for the WHEN clause)
>
> Instead of doing them in this order:
>
> (1) (for the action node)
> (1) (for the WHEN clause)
> (2) (for the action node)
> (2) (for the WHEN clause)
>
> I think that if we re-factored getTriggerActionString() into
> two different routines, for these two different tasks, then
> we could have CreateTriggerNode call the code in the order (1,1,2,2)
> instead of the order (1,2,1,2), and then that might fix the problem.
>
> So in CreateTriggerNode, instead of code that looks like:
>
> transformedActionText =
> getDataDictionary().getTriggerActionString(actionNode, ...);
>
> // If there is a WHEN clause, we need to transform its text too.
> if (whenClause != null)
> transformedWhenText =
> getDataDictionary().getTriggerActionString(whenClause, ...);
>
> We'd have code more like:
>
> getDataDictionary().examineTriggerNodeAndCols(actionNode,...);
> if (whenClause != null)
> getDataDictionary().examineTriggerNodeAndCols(whenClause,...);
>
> transformedActionText =
> getDataDictionary().getTriggerActionString(actionNode, ...);
>
> // If there is a WHEN clause, we need to transform its text too.
> if (whenClause != null)
> transformedWhenText =
> getDataDictionary().getTriggerActionString(whenClause, ...);
>
> What do you think? Is this idea worth trying?
>
> thanks,
>
> bryan
>
