I’m having an issue working with flow variables inside a Case Switch. I know this topic has been discussed in several threads (for example, Case Switch Flow Variable Problem or Case SWITCH End (Flow Variable) Unexpected Behaviour ), but I wanted to ask if there have been any updates or improvements. Do you know if Knime is working on solving this bug?
I have a fairly large workflow that involves both tables and flow variables. At one point, I need a Case Switch to operate on flow variables and update them within each port (depending on the port, I need to update certain variables, others, or a combination of both). I’ve tried working with the Case Switch only using flow variables and only with tables as input and output, but neither approach works as expected: I want the values of the flow variables to propagate correctly to the end. I’m attaching a very simple workflow as example that demonstrates this issue. Anny suggestions or comments?
As alternatives to skip this problem, I’ve read about using the “Table Row to Variable” node or creating new variables and then renaming them, but these approach complicate and slow down the workflow.
The issue is still unresolved and requires some core changes, so I can’t guarantee a timeline for the fix. I willl add a +1 to the ticket (internal reference: AP-14348).
As you mentioned above, the workaround wold be using a Variable to Table Row node at the end of each branch and convert them back to variables after the case switch end node as shown here.
In the example workflow you shared, instead of using Table Row to Variable node inside the loop, if you use it at the end after the case switch end node, you will get the desired output.
Hi @p_mg, if you are using KNIME 5.3, which from your workflow it looks like you are, I think that the Variable Filter node could reduce the pain a little.
I modified your workflow a little for a use case where the Variable Expressions are both needing to make use of the existing value of colinteger, so that on branch 0, the required result is that colInteger becomes original value + 41, and in branch 1, it becomes colinteger + 42.
By creating a new variable colintegerTMP with the value of colinteger, and then using a variable filter to remove variable colinteger, the colinteger variable is no long present via the upper branch when the lower branch is active.
Each variable expression can now perform its calculation and create colinteger.
At the end of the process, a further variable filter removes the now redundant colintegerTMP.
Of course, if you don’t need to use colinteger in the calculations, and just want each branch to create it from scratch, simply putting the first Variable Filter in to remove “colinteger” if it already exists should be sufficient.
Thank you both very much for your responses. I have been testing both solutions, which is why it took me some time to reply. Both options gave me some insights, but I couldn’t implement either due to another issue I found: flow variables cannot be deleted (I opened another forum thread about this), which made the solutions unworkable.
I couldn’t fully apply k10shetty1’s solution because I need to operate on tables while filtering by flow variables, and having to keep updating these values makes it very challenging to maintain a readable workflow. Additionally, I have some flow variables of type stringArrayType, which complicates the use of “Table Row to Variable” and “Variable to Table Row” due to the limited operations available for these types of variables.
I had to lean more toward the solution proposed by takbb, but with many adjustments due to the issues mentioned above. Furthermore, another problem I encountered is that the flow variables that are created inside the port 0 of the Case Switch Start are carried over to the Case Switch End even if the active port is not that one. Also, in one of the output ports, I need to output a table. For this reason, the only option is to use a Case Switch Start with flow variables and close it with both a Case Switch End for tables and another for flow variables. Therefore, instead of renaming the variables before entering the Case Switch Start, I created new variables with different names inside, and once I close the Case Switch, I rename them and reintegrate them into the input tables.
Another issue I ran into is that the flow variables created in port 0 of the Case Switch Start are carried over to the Case Switch End even if it’s not open. This is also quite frustrating because I need to clean up at the end, even after cleaning inside the node itself with a ‘Variable Filter’ before the output.
In summary, this bug in KNIME is very tedious, complicated, and inefficient, especially since flow variables cannot be removed from tables. I encourage Knime to fix this bugs as soon as possible because working on non-sequential algorithms becomes extremely challenging.
Hi @p_mg , when you said “flow variable cannot be deleted”, this is true for many versions of KNIME, but the Variable Filter I included (introduced in KNIME 5.3, I think) should do exactly that, but I agree that the issue of competing flow variables, even on inactive branches is frustrating.
