Parameterizing nodes on their columns selection - *dynamically*

Dear Community,

i am facing a case which i tried solving 2 ways (detailed below), but none of them worked. So seeking for your help and/or ideas.

The case is: i am developing an interface which enables our users to select which columns they want to GroupBy on. The available column names are totally dynamic, so is their count. Doing so, i wanted to have a Multiple Selection Widget, parameterized on its possible_choices parameter.

My attempt #1:
Assumption: array-size will split the single 0 parameter (being an array) into as many parts as set by array-size.

  1. Calculate how many possible options i have (flow variable = preprocessing_GroupBy_ArraySize on my screenshots)
  2. Collect the candidate columns (column names) into a collection, using Create Collection Column node.
  3. Convert (2) into flow variable
  4. Use (1) in Multiple Selection Widget node’s possible_choices/array-size parameter, and use (2) in its possible_choices/0 parameter

This attempt is failed, as conversion from data to variable simply does not happen for arrays.

Where is $${Spreprocessing_GroupBy_PossibleColumns}$$ variable?

Is this a bug or working as expected?

My attempt #2:
Assumption: non-existing flow variables are not taken into account, in case array-size defines they are not needed at all.

  1. Calculate how many possible columns are there, into a flow variable (array-size)
  2. Get column names as single row data, using a Column List Loop to name the columns as PossibleColumns_n, convert this into all those flow variables (on my screenshot they are named as preprocessing_GroupBy_PosibleColumns_n)
  3. Pass array-size to Multiple Select Widget’s possible_choices/array-size parameter, and the PossibleColumns_n to its possible_choices/0…n parameters

Since we had to initialize all these parameter settings inside Multiple Selection Widget like this: * ,
the question raises:
A) What if i pass a broader set of columns (i.e. more flow variables are generated than set in the parameterization of the node)? ==>> Array-size gets larger, but 0…n parameters do not follow, therefore the to-be-overwritten “pseudo-options”, added in the general config of the node, appear in the default selection.
B) What if i pass a narrower set of columns (i.e. less variables are generated than set in the parameterization) ==>> Error message. Even though array-size told the Multiple Selection Widget node that the last ones of the 0…n parameterization should not even be used, error message is dropped as there are non-existing flow variables set in the parameterization.

All the above drives me to the conclusion that we cannot set dynamic amount of parameters, at least not this way. Maybe i am missing something trivial… But in case the community has some ideas how the above goal could be reached, please dont hesitate to share the ideas with me :slight_smile:

Attached is a sample workflow to illustrate what i meant.Dynamic Nr. of Parameters.knwf (322.5 KB)

Thank you in advance,

1 Like

Exactly and this is a major limitation of knime. Hope gets fixed in version 5…

What might work is doing the grouping in a python node with pandas.

1 Like

Even though i hoped for a different answer, i am thankful for ensuring me that it cannot be done.

Thank you for the tip with python as well. i will try mimicing the needed behaviour with coding.
Unfortunately, the quite simple groupby is just one action what needs dynamic amount of parameters, but will consider doing the others also with custom python/java coding.

One other “solution” coming to my mind is checking the columns count, and make an arbitrary amount of additional constant columns to have like 200 parameters always, and feed all these into the UI field. Would be ugly, but at least would (might) work.

Hi there @csabbooca ,

if you can’t make it with Multiple Selection Widget node you can try some other node. For example Table View node which offers multiple row selection. Also you can use Column Filter Widget node if I got you right. Have a look at this workflow example.

Now to your use case. Some nodes are a bit tricky to dynamically control and one of them is also GroupBy node. Here is a topic where it was discussed: "Group by" column names coming from external source so take a look.

Hope this helps.


1 Like

Thank you Ivan, will definitely take a look!

1 Like

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