New Row Filter neither supports wildcard, regex, boundary filtering etc.

Hi,

I noticed that the new row filter does not support wildcard nor regex matching for certain types like XML. I write certain types as I assume this issue is present for others too.

Old

New

Update
Even for integer this is not possible anymore. Nor is it possible to filter by boundaries. The new row filter node is a huge step backwards or do I miss something crucial? If not, the new row filter has become quite dump, didn’t it?

Best
Mike

Hey Mike,

the row filter actually became way smarter compared to the old one, but smarter might not always be better :wink: . While the old one was treating everything as a string we are now making use of the actual data types. This might sound like a detail, but will allow us to introduce more type specific filter inputs in the future. Think of calendar ranges for date&time values as an example.

That being said I totally agree with you. I created a ticket to bring it back (internal reference UIEXT-2027)

Greetings and thanks,
Daniel

4 Likes

Hi Daniel,

certainly a better approach … i.e. I could imagine to provide an XPath to filter all XML where it matches. Though, the missing options being gone now and that not have been announced, at least I didn’t noticed anything, really feels like a kick in the guts.

With the issues around interactive view rendering in CUI and this regression I find it hard to recommend updating to 5.3 given the “surprises” identified. Without pressuring too much, to you have an idea about the time to resolution?

Best
Mike

1 Like

Hi @DanielBog , I’m totally with @mwiegand on this one, (and I know you’ve said you agree, so I don’t want to labour the point), but actually not having the easy ability to include the deprecated Row Filter in a new workflow is going to be incredibly painful while there is no obvious alternative node. Yes we could start using rule based row filters instead, but is that really what is expected, or was this just an oversight?

I confess I had played with the new Row Filter prior to the release of 5.3, and had liked what I saw in terms of first N rows and last N rows, and thought it generally to be an improvement, but hadn’t spotted the lack of the existing options, and would have assumed anyway that the old Row Filter would have been made “legacy” but still selectable.

I considered going to the hub to drag down the old node, but that option isn’t available, as there is no draggable icon for it.

The wording says:

This node has been deprecated and its use is not recommended. Please search for updated nodes instead.

but that isn’t of assistance unless there is an updated node that can achieve the desired result (e.g. with regex and wildcards).

Is there any reason why the old node cannot be made available in the node palette, given that it is obviously still available within KNIME AP 5.3?

I recall there was a “hidden” option to include something like /deprecated in the search but I cannot get that to work now, so maybe I have the wrong word or it’s been removed.

The only option I see at the moment is to import a workflow such as this into 5.3, and then copy and paste the required Row Filter (deprecated) node from it when needed, which is what I have now done within my 5.3 installation.

Deprecated Row Filter.knwf (4.2 KB)

2 Likes

Further elaborating on what @takbb wrote, I tried to add the 5.2 repository in an attempt to install the deprecated not but without success. Adding to the already high difficulty is the fact that the install window lacks the option to chose a particular repository (and manage them too). That inconsistency I have reported during the community hacking days.

Any suggestion to for any fallback until this gets addressed? I currently have none except going on a hunt for a deprecated node to copy and salvage that.

Hey,

first of all the old row filter is still available and installed by default. You can get deprecated nodes in the node repository by adding “//deprecated” at the end. So no need to copy&paste between old workflows.
It would still be important for us to hear about what exactly you are missing, so that we can get the new row filter in a more useful state as soon as possible.
So far I got:

  • Wildcard/regex missing for some datatypes (which are the most pressing ones?)
  • Boundaries missing, but this could probably be solved with two filter criterions?

Greetings,
Daniel

3 Likes

Hi @DanielBog , thanks for the info about the //deprecated. I knew there was something like that but hadn’t managed to make it work. It was the two slashes!! Got it now though! :slight_smile:

Generally I agree that the new Row Filter is a step forward on the old, whilst lacking specific “edge” cases in terms of “other” data types mentioned, which of course isn’t great if you are using those cases. I agree that for the boundaries (using multiple criteria) and regex/wildcard on strings, it actually is likely to give more flexibility than the old node.

1 Like

Hello,
In the same nodes family, new minimalist ‘Column Filter’ node, is lacking of functionalities in the same way.

Is there an open ticket for this?

BR

PS.- I’m not in the right PC just now, so I can’t check about Row Splitter…

2 Likes

Hey,

can you be a bit more specific on what it is missing?

Greetings and thanks,
Daniel

Thanks for the workaround. I suppose you mean it literally as by just using “deprecate” the row filter is not found:

Using //deprecated however, yields an unsorted and unstructured list from which I am not able to identify the row filter note easily. Only by scrolling to the very bottom to load all nodes and going through the list a view times I was able to spot it.

This relates to the topic raised during the 5.2 community hacking days that the node repository is in desperate need of some love :wink:

PS: It just incurred to me that using // resembles the usage of a filter like //IO. Hence, typing row filter //deprecated does the trick but it’s certainly not intuitive.

Though, I wonder why //IO and enabling the filter doesn’t yield the same reesults.

image

image

Hey,

this is due to the fact that only literally //deprecated is working this way. The tags are something different and also work different :slight_smile: .
I am not sure if //deprecated needs to be intuitive, as we want it to be sort of hidden. We should try to have as few reasons as possible for the deprecated nodes (best case none at all).

Greetings,
Daniel

1 Like

Ok, I assumed this little trick would work for all as //deprecated kind of represented a filter. Ideally you are right about that nice trick not being required to be intuitive but in our little inconvenient scenario a slightly more visibility would have helped.

Maybe it’s an idea to display, at the very bottom, a button / link to display deprecated nodes based on the filter combination applied?

Furthermore, that nice //deprecated trick does unfortunately not work on Classic UI and by default, for apparent reasons, the deprecated notes are not displayed.

@DanielBog might also be worth checking for the expression language in general which would also affect the new expression node

Although this does support Regex so that would be a fallback …

1 Like

@DanielBog Another thing that comes to mind is that there seems to be some issues with the process (but I don’t know how to fix it).

  • I think there should be a clear standard for what goes into //deprecated and when
  • Similarly, there should be a standard for when nodes in KNIME Labs should enter formal use instead of just staying there (such as the column expressions node that has existed for many years, of course, there is now an expression node, but it was a problem before)

Basically, the above two things are handled in reverse. Of course, I completely agree that KNIME has its own priorities, but I think the process should be more consistent.

For classic UI, I agree with @mwiegand it is better add option at vertical ...
image

One more thing to the list. Path support, since that data type was introduced long time ago, seems to never have improved noticeably. With the “new” node that would had been the perfect opportunity.

But, nah … why should we. Kind of sad to see things evolving that way :cry: The new row filter node doesn’t even follow the 80-20 rule which was once stated to be followed when the Modern UI started to sneak into Classic UI slowly and now increasingly faster degrading UX.

Apologize if that is too harsh but so is that and other surprises. The nightly build log already lists 5.4. Do you have more details about 5.3.1?

https://www.knime.com/nightly-build-changelog