Rule Engine string return bug

Dear KNIMErs,

The Rule Engine nodes appears to have a problem with string returns sometimes.

I spotted that for the Rule Engine Variable node, which would not recognize/parse return strings containing some special characters like commas or plus signs. So insead of returning whatever the rule says to return (like "+scale_x_log10()"), it erroneously returned empty strings. :-( Escaping them with a backslash worked partly, as the backslash then became part of the string as well and needed to be replaced. Somehow the automatic type detection is confused there...

Thanks in advance for looking into this, here's hoping that maybe a pre-2.10 fix could still be possible. :-)


I am afraid I cannot reproduce what you described: (


Also tried with the Rule Engine node and seems to be working fine. To be honest I used the 2.10 preview for the test, but I do not remember any fixes that might cause this behaviour. (Disclaimer: I have quite bad memory so not remembering does not mean too much; also usually I get the bugs related to this node as I put them there. This kind of bug seems hard to imagine given its implementation.)

If you mean some String concatenation (like concatenating a fixed string to a column/flow variable when a rule matches) in the outcome or reference to a regex group for example, these kinds of operations are not supported.

What can/cannot the rule engine nodes do in the outcome:

They can be a constant, a flow variable or a reference to a column. The escapes might not work as you would expect based on the highlight, as the escapes are not supported in Strings, each \ acts as a backslash and you cannot write a " in a String constant. (In 2.10 you will have an option to use escapes using Perl-style strings, so you will be able to write /"\\ \// to mean "\ / (quote, backslash, space, slash). The syntax highlight will also be improved, so the seems-to-be escaped syntax (ex.: "\" or "\\") will not look good/bad in the editor.)

They cannot contain operations, comparisons, only the first matching rule will provide results to the outcome, if there are no matching rules, a missing cell will be the result.

The behaviour you described most probably caused by rule match/not match, though that do not explain why it works with escaping. Do you have an always match rule (TRUE =>) at the end?

Could you please give more information how to reproduce what you experienced? Thanks, gabor