delete flow variable

KNIME Analytics Platform
1

Hi,

Is there a method to delete a flow variable?

Thanks

3 Likes
2

No, flow variables cannot be deleted.

3

I just wanted to comment that this is pretty annoying.  I have a large workflow and just hit a bug where a "Java Edit Variable" node was assuming that a flow variable was new.  But then I created a variable far upstream with the same name.  Now that node crashes.  It would have been much better if I could have deleted that flow variable upstream after I was done using it.

2 Likes
4

Hi aborthwick,

Yes, I encounter this often when I create metanodes that are used several times throughout the workflow.

You may have figured this out already, but the workaround I use whenever I create a new variable with a Java Snippet node that might be used multiple times in a workflow is to precede the JS node with a Java Edit Variable node. The Java Edit Var node should be configured to create a new variable of the same type and name of the variable in the Java Snippet node. Connect the Java Edit Var node to the left "mickey mouse ear" i.e. flow variable inport of the Java Snippet node. Now when you add the same named output variable in the Java Snippet node it should be configured to replace the already existing variable instead of create a new variable. This prevents you from getting the error about the JS node trying to create a new variable that already exists.

One more point... apparently the "Sub Node" feature (which as similar to the Meta Node feature) will prevent variables from leaking from the contained nodes. There isn't much documentation yet but I understand from KNIME folks that more support is coming and eventually sub nodes will be preferred to meta nodes.

Hope this helps.

Don

5

Hi Don,

Thanks for your reply.  I would use the Sub Node feature in order to prevent variable leakage, but the problem is that a Meta Node is configurable whereas a Sub Node can't be configured.  In general, most of my Meta Nodes have configuration parameters.  

Hopefully this is fixed in the next release of Sub Nodes.

Andrew

6

I'm curious. Why is there no way to delete flow variables? And by "delete" I mean "make inaccessible for downstream nodes".

Right now I have a growing number of flow variables. It would be nice to have something like the Column Filter node but for flow variables, so that I will only see the variables that I think I need for further downstream processing.

1 Like
7

Maybe I ask the opposite question. Why is it necessary to delete flow variables? Honestly I never had the feeling I need to delete them. They are just there.

 

If you don't like them, you could also put the functionality inside a wrapped node. Flow variables created inside a wrapped node are not available outside of the node (if you don't want them to be)

3 Likes
8

I use a wrapped node, which protects the scope of any flow variables within it, and use quickform nodes to provide configuration options. These allows for parameters and selections of input table values. 

I have found that with this any corruption of flow variable from different parts of the workflows can be prevented. I also use call local workflow node to create factories so I can have a generic workflow that passes control to local workflows to deal with anything specific. This keeps the scope of the flow variables precise to where it is needed. 

David

 

9

It is not strictly necessary to delete them. But it would be nice if that were possible.

I am working on a fairly large workflow and there are many variables that are only specific to certain parts of the workflow but they still show up in the setup for nodes that are further downstream.

Certainly, wrapped nodes/metanodes can help, but they don't always provide what I want. Sometimes I want to export a specific variable from a metanode while discarding all other variables. I don't think this currently possible.

For me it is mostly an issue of having a clean workspace while still being able to express myself with any variables that I would need to describe what I want to influence. In most programming languages you also have local and global variables that you can use to give names to intermediate or permanent values. And the local variables are always gone after a function returns.

2 Likes
10

Hi, it could be necessary in some situations. For example, if I use the extract context properties node, it creates incompatibility with the Python nodes that throw the error "Requested string value from cell with type: STRING".

So if I use the David Ko trick wrapping the extract context properties and keep only the variable I need from context and rename it the error disapear.

Fabien

11

I have the same problem merging two different workflow I have problem with flow variable with the same name, a node that permits to delete or rename a folw variable it will be very usefull

12

Hey @Iris,

I try having a more canonical view on that:
A variable is defined by a name, a type and a visibility. “name” is the unique identifier within the “visibility”. “type” defines the range of valid values and allowed operations. “visibility” tells something about who is allowed to read/modify a variable (realm).

A variable from a realm may under no circumstances be accessible from another realm (security) - else wise the value is no more trustworthy and/or a security leak may arise.

From that point of view, a kind of “garbage collection” or “limited visibility” makes sense!

@aborthwick: A common approach to circumvent these situations is by using realm-bound prefixes (e.g., variables used during data load are prefixed “dl” while variable used within processing are prefixed “pc”).

Kind regards,

Patrick

1 Like
13

Hi @Iris,
I would use wrapped metanodes for encapsulation flow variables.
But, there is one usecase, which prevents using wrapped metanodes:
I have hundreds of interactions with databases and I can’t using database nodes within wrapped metanodes, if I want to start my workflow as a scheduled workflow on knime server.
The reason is, that I can not get the workflow-credentials into the wrapped metanode! The only way to do this, is to use quickforms for setting username/password. But this won’t work with scheduling…
So I have to deal with all flow variables along the complete workflow…

Another thing is: I created some generic Nodes for our organisation which contains database-stuff. But with wrapped Metanodes we cannot use these (see above). And so, all colleges get flow-variables they won’t have…

1 Like
14

I absolutely agree with the convenience of having a Variable Filter node.

8 Likes
15

Hello @mpenalver,

your request has been noted. (Internal Reference: AP-16515)

Br,
Ivan

9 Likes
16

The inability to filter flow variables really causes hassles in creating large workflows that have duplicate process components or node collections. It builds up a massive confusing backlog of flow variable clutter, it causes duplication of flow variables when reading and writing variables to memory, and in general it is just bad practice to leave a confusing mess of “single process use” flow variables in the larger workflow pool at risk of being used in error on a later date… I don’t get why anyone wouldn’t want the ability to filter variables? Is this still not possible?

4 Likes
17

I guess only “remove them completely” for parts of the workflow by using a component
br

1 Like
18

Components not passing flow variables does help, but the flow variables in a workflow that control large numbers of components can’t be wrapped in components…

19

This must be a relevant issue for a lot of users considering that it has 2800 views. :wink:

1 Like
20

Hello @iCFO,

Nop. Have added +1 to existing ticket mentioned above.

Although number of views is relevant topic is pretty old so might be a bit misleading…

Br,
Ivan

1 Like