As of version 5.4.4, I’m puzzled how Knime has made something some fundamentally simple as IF and CASE logic so convoluted that even AI can’t figure it out. This was the reaction after AI failed to reason it’s way through the IF node:
”This is maddening, and you are right to be confused. The behavior you’re seeing means the IF Switch node is not working as it should, which is a known and incredibly frustrating issue in some KNIME versions where the flow variable isn’t read correctly on each iteration.
Let’s abandon the IF Switch completely. There is a much better, more reliable set of nodes for this.”
To be fair I even watched this video which is from an earlier version of Knime: https://www.youtube.com/watch?v=E0-zPQsQhIE
I did exactly what the narrator did and it still didn’t work. After countless attempts the IF Switch continued to only go through the top port. I passed “top” and “bottom” to it through a flow variable just like the video and it always went through the top.
So I switched to a CASE Switch thinking it might behave differently. I used a rule engine node and confirmed it was passing 1 and 0 as a flow variable to the case node. What’s curious is that the port index needs a number, but the data type is string. So I passed a string value and the data showed 1 or 0 was coming through. Immediately I get an invalid output port “PortChoice” specified. PortChoice is my flow variable with values 1 or 0 and the correct data type. I also changed the logic to “0” or “1” in case the data type conversion was confusing it. By the time it gets to the flow variable however it’s already a string, so that didn’t matter, it still failed.
Another question is why is the append column a boolean flow variable? It’s appending a variable to the data set, like it’s supposed to, but then it’s called “new-column-name”, which at first glance is a bit confusing. It is passing the value correctly however.
Like I said, shouldn’t be this difficult to configure.
¯\_(ツ)_/¯
Have to admit it is a little hard to follow what is going on when just snippets of your workflow are provided and I don’t get at all what this has to do with Goolge Sheets API Limits. To properly help you more screenshots or maybe a minimal example of the set up that repliactes the problem would be good.
True, IF Switch configuration with variables is way trickier than it should be.
It accepts an string type variable with a value of “top”, “bottom” or “both” . Unfortunately it’s case sensitive so “Bottom” does not work.
To figure out how the settings should be I often create a flow variable right out of the node configuration. So I can see how the variables should look like.
The Case-Switch
needs a string type variable. Ports start with 0!
For example this activates the third port of the CASE Switch
1 Like
A simpler implementation of this would be to just let the user add (n) output ports and define the values for each. Then IF, ELSEIF, ELSE or CASE WHENs would be possible without a lot of confusion. Pass in a value and it goes down the path you defined. The CASE Switch Start is almost there, but you can’t define the expressions for each port. Simpler is just better.
1 Like
Google Sheets has a payload limit. You can’t even import a file that has more rows than the API will allow. So with Knime you have to create a chunk loop and incrementally update Sheets. The Google Sheet Writer doesn’t append and it can’t load more records than the API will allow, so the logic I’m testing is to create the sheet with the initial payload and then when the chunk loop reaches the second iteration it switches to the Google Sheets Updater which continues to append subsequent records.
First iteration:
Subsequent iterations:
Despite receiving top and bottom the IF SWITCH always go through the top port. The loop itself works fine, but only for repeating the Write operation.
This is the value coming through the top port, which makes no sense since it’s binding to the flow variable PortChoice which has the value “bottom”. The value is being passed on the flow variable and is changing correctly, but the IF SWITCH isn’t evaluating the path correctly.
I am a little confused - where do you actually turn the value from the column “Port Choice” into the Flow Variable “Port Choice”?
This screenshot is from your initial post:
Is that where you currently are “creating” your variable? If so I think there is a misunderstanding: The PortChoice Variable created above will have the value of “PortChoice” as this is the name you seem to give the new column. It does not take the value that is shown in any of the rows of that new column.
I recommend to try the following (provided my assumptions above are right):
-
remove the variable creation as per above screenshot in Rule Engine
-
Add Table Row to Variable node after rule engine and connect flow variable output port to IF Switch:
-
This will assign the value in the first row of the output table of Rule Engine to variables that are named as per the columns of the table - so this way your PortChoice should pick up top or bottom
2 Likes
In the flow variables of the rule engine the value is being passed to the flow variable PortChoice.
To make sure it’s passed downstream as a flow variable I’m connecting the output flow variable to the flow variable input of the IF SWITCH.
The IF SWITCH is receiving the input through the PortChoice flow variable.
1 Like
I have replicated the set up I believe you have here - if you inspect the Flow variables you see flow variable “PortChoice” with value “PortChoice” (the name of the column you create, which is what the setting from your first screenshot does).
For some reason it actually keeps both branches active in this way, resulting in both branches being processed and resulting in duplicates in my Loop End
Compare this to this set up, where Table Row to Variable is used:
Variable has the correct value and only one branch is triggered.
Here is the workflow containing both options (top "yours”, bottom “my suggestion”)
IFSWITCH.knwf (70.1 KB)
Ok, I’ll take a look. Seems like six and one half dozen, but maybe it’s a bug.
1 Like
Looks like you’re using a later version. I have 5.4.4 and 5.5.1 installed.
1 Like
Looks like it runs anyway.
1 Like
Hopefully it just works - not using any fancy nodes so should be backwards compatible I hope…
If it doesn’t - maybe take a backup of your version, disable the flow var creation in Rule Engine and use table row to variable node and see what happens…
You’re approach works. You get the prize. I think it’s a bug, because the only difference between our approaches is that you’re using a table row to var to pass the flow variable and I’m mapping it directly from the output flow variable. That’s poor design. No matter, it works. Kudos for your suggestions. So this model works.
1 Like
I have to politely disagree - there is an important difference between your approach and my approach:
- When you use the text box right next to a flow variable setting in a flow variable tab, in your case you are using the setting to set the name of the new column to be created in your rule engine, you expose the value of that setting, in your case the name of the column that you add (PortChoice) via a flow variable => You create a Flow Variable “PortChoice” and its value is “PortChoice” (not top or bottom)
- My Approach exposes the value of the first row in the column PortChoice via flow variable => Flow Variable “PortChoice” with value top or bottom (depending on the iteration)
The thing were I tend to agree that this behavior is either a bug or poor design is that if in your case the value “PortChoice” is inserted where the setting should only allow top, bottom or both as valid values, that it defaults to “both” and keeps both branches active… I’d at least expect a warning if not an error here
1 Like
