Feature Request: Temporarily Disabling Nodes

Hi all, I’m not sure if this has been requested already or not but I couldn’t find anything similar.

When programming, we often comment out code in order to isolate problem parts or while testing. Same in KNIME - we move nodes around, replace data flows and so on. But sometimes I find it frustrating to take a string of three nodes, remove the middle node, and hook up the first with the last again - especially if you’re dealing with a workflow that for various legitimate reasons has these nodes very far apart from each other on the workbench.

I thought it would make sense to request a feature to allow a user to disable a node - essentially, ignore anything it does - and have the data flow continue past it, like commenting out code. This is really useful when you have a complicated workflow you’re working on and you need to test something without a row filter, or without some string manipulation and so on - instead of removing the node and re-connecting your other two nodes before and after it, you could simply “comment out” the node and continue.

Cases where this can pose a problem include nodes that convert data from one type to another - the data cannot flow onward if the node doing the actual converting is “commented out”, so for this suggestion to work it likely can only work within the same type of data stream (e.g. tabular data, or DB connections, or model data etc).

I’d imagine disabled nodes would need to be clearly delineated as different from active nodes, such as by making them transparent, or changing their colour, to indicate to the user clearly and intuitively that this node exists but its functionality is temporarily disabled.

Any thoughts? Would anyone else find this useful?

3 Likes

Hi,
thanks for your suggestion! I also thought about this before, but I don’t know if it would really help much. When I want to “comment out” a node, I simply connect the node before it to the node behind it, automatically replacing the connection. This requires just one user action. Additionally I think there are not that many cases where it is actually feasible. When the table structure changes, it does not work and, as you mentioned, when the type changes it also does not work. And what happens if the node has two inputs? Which one is propagated? So in my opinion there are cases where it makes sense, but not enough to make it feasible implementing it.
Kind regards
Alexander

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