Rule Engine: An Accidental Integer Output Among Long Values Impacts Subsequent Joiner a Very Strange Way

Today, I faced a very strange problem. I was joining two tables using the Joiner node and I realized two rows kept not joining despite the fact their joining columns had the same values. I couldn’t figure out what was wrong. It was like this example.
Top table:
image
image
Bottom table:
image
image
The Joiner Node’s settings:
image
And now. Surprise. The Joiner Node’s result:
image
And I’m pretty sure the last five rows should have got joined with the third row because the bottom_id values 5 from the bottom table ire equal to the top_id value 5 from the top table.

So what’s wrong. Types. But the Joiner Node always complains about type-mismatch (and it insists matching int and log values is a type-mismatch) and more over the tables joined up to some extend, so type can’t be the reason.

Unless it is the reason.

Let’s see the whole workflow:


There is a Rule Engine node in the worklow which is configured this way:

Please notice that an Integer is the assumed type of the result of the first row of the Expression. Well, this made me pretty clear what was wrong with my workflow.
But let’s see the Node’s result:
image
The column bottom_id is still indicated as of type Long. But I’m sure the KNIME works internally with the cells I tagged with blue collor as if their were of Integer type so it does not match them with the appropriate value from the other table in the Joiner Node.

Well, this was creepy and it took some time to investigate.
The scary thing is KNIME has an underlying logic or magic it uses to decide what to do with cells of different type or different origins. You can do an experiment. Do have a table with a long cell. Use the Table Row to Variable node to get a Flow Variable from the Long cell. Now you can see you don’t see the variable in Flow Variable List area of a Rule Engine Node. So the variable is of type Int but KNIME knows it was made of Long cell and does not offer the variable here. I spent a portion of time figuring out this. It’s magic.

Nevermind.
From the point of view of this topic I tend to state a work with long values is often not very convenient. Realy, there are not many nodes capable of work with cells of type Long. Let’s take Math Formula. It’s result is either Double or Integer if you choose that option. But not Long. The Rule Engine Node is another example.

1 Like

Hi @jan_lender -

I appreciate the detailed writeup and discussion of this issue. Would it also be possible for you to post the workflow itself? I’d like to pass it to a developer to see if they can shed any light on what’s going on here. Thanks!

1 Like

Hi, ScottF,

please find attached export of my workflow

Rule Engine and Join by Long Value Issue.knwf (14.3 KB)

Regards, Jan

1 Like

Got it, thanks! (Ticket created: AP-15320)

2 Likes

Nice one for figuring out this one @jan_lender :+1:
Br,
Ivan

1 Like

Hi Ivan,

Oh, thanks a lot!

Hi @jan_lender,

was thinking others must have came across it as well as Rule Engine node is frequently used node and whether they have figured it out, found a workaround or ignored it haven’t seen this reported on forum.

Regarding the long flow variable type. It’s pretty new and not every nodes supports it (same with list flow variable for example) but it is on the list and coming.

Br,
Ivan

1 Like

Well, in my opinion, the bad thing is you can’t set a column of type Long a literal value using the Rule Engine node unless you cause the issue I described. In Java, there is a suffix L you ad to the end of a literal number to convince the compiler the value is of type Long. From this point of view I would always prefer the Column Expression node which is much more powerful.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.