KNIME AP 5.3 - Sorter node - Missing functionality with Flow Variables

[ajackson]

With KNIME AP 5.3 I noticed the Sorter node’s Flow Variables have changed, removing some functionality.

Is there a simple viable alternative, or can this prior functionality be restored?

Prior to 5.3 I was able to set Flow Variables to get a string list/array, like so:

This would then yield:

With 5.3, the Sorter node’s Flow Variables look like this:

Which yields:

This feels like a step backwards.

• To get flow variables out of a Sorter node, my only option is to create individual variables for each criterion, which isn’t great for larger lists.
• To get flow variable info into a Sorter node, there’s no way to provide a Sorter node with an array for the sort criterion any longer. I have to manually specify each item.
• If I need to add an additional sort criterion, it can no longer by done dynamically - it has to be manually adjusted in the workflow.

[MartinDDDD]

You can still access the „old“ row filter.

I think you can find it by typing either “//deprecated Row filter” or “Row filter //deprecated” into the node repository search field.

[ajackson]

I am working with the Sorter node, not a Row filter.

The “Row filter //deprecated” search did return the deprecated node for a row filter, but the same trick doesn’t work for Sorter.

[MartinDDDD]

Apologies - my bad. Misread your post.

I did a search and it looks like there’s indeed no deprecated version available.

Think will have to leave this to a KNIME Team Member to look into.

My assumption was that in order to ensure backwards compatibility there should be a deprecated version but that’s clearly not the case here.

[ajackson]

I appreciate the response non-the-less

[ajackson]

Bumping this - is there a Reference Row Sorter perhaps?

[takbb]

Hi @ajackson ,

I’ll start by saying I don’t have a solution, but I am happy to help bump the issue by providing an example of the problem.

I thought I’d take a look to see what happens when a sorter from KNIME 4.7.8 is imported in KNIME 5.3.2, configured programmatically, and I can certainly see that this is not ideal to say the least.

Having imported into KNIME 5.3.2, I have re-exported the flow

Sorter Investigation.knwf (104.1 KB)

In this flow, the upper Sorter was configured in KNIME 4.7.8 and continues to operate based on the sorter settings provided by two String Array flow variables.

The sort config can be altered in the two components and on re-execution, the node behaves according to the config.

It does not appear to be possible to configure the lower Sorter in KNIME 5.3.2 to behave the same way.

Opening the config of the above sorter, it says that the configuration is deprecated.

I confess to being surprised by this. In my view functionality should only be deprecated when there is a viable alternative facility provided but as you have already mentioned, no alternative appears to exist.

The node can clearly still handle the old config, but it does not appear possible to configure a newly placed node to work the same way.

I am not a fan of the move away from array variables for the new config and I too would like to find a viable workaround or facility that brings back this very useful configuration mechanism. I am sure you are not alone in using it. Sorry I don’t have any good news for you but let’s hope there is some forthcoming.

[takbb]

My above post gave me an idea… if a configured copy of the Sorter Node still works with the supplied array then “all we need” is a copy of the Sorter node that is already pre-configured to use array variables. Then we “just” need to switch in/out the required variables …

… and so another component is born

Sorter (Array Configurable) – takbb

I have put this in my “experimental” folder on the KNIME Community Hub.

Here is an updated version of the above flow, using this component in KNIME 5.3…

Sorter Investigation 5.3.knwf (144.6 KB)

[ajackson]

Yikes that’s quite the component… thanks for putting it together. I’m still studying it =)
And thanks for re-framing the issue too – I agree entirely about the topic of deprecating without replacing. It would be nice if new/refreshed nodes were available in a ‘beta’ package before they are put into the regular packages, so that we can have the opportunity to test them prior to mainstream release.
Thank you again, @takbb !