it feels that since quite some time support for the data type “Path” wasn’t extended. I.e. a Path column can be chosen as a column to get filtered but not as a value. Trying to use the String representation seems to not work. Furthermore, the Test Data Generator does add URI but not the Path Type.
Path not Supported as Filter (variable) Row Filter
you are most welcome. I happen to notice another node which would significantly benefit from receiving support for the path variable. That happens to be the Wait Node
Here is a screenshot where I temporarily added it just to display the incompatibility.
At this point it really feels like, as was my impression from the beginning when the Path type was introduced, that it was done not quite well. As it stands, the path type is neither properly supported by rather common nodes like row filter nor file handling specific ones as mentioned above.
No need to create another thread for the missing PATH type support on additional nodes. This is an issue that has been raised a few times by the community in recent months, and the developers are definitely aware! They are doing the usual tricky bit of balancing resources from their side - but it’s still good to get detailed feedback like this, since the squeaky wheel gets the grease
Thanks @ScottF for letting me know this is also a pain point for other Knimers. Talking about squeaky wheels (I like that analogy of yours a lot) … if basic data types, absolutely necessary to work with and save data, are not properly supported, how much more squeaky can it get?
I can imagine the many path type variants – local, remote, absolute, relative etc. – are increasing complexity manyfold. But wouldn’t this indicate one integration is too complex (Eierlegende Wollmilchsau) and suggesting to follow “divide et impera” by either:
Defining the problem and working through it path type by path type for each identified node OR
Creating distinct remote nodes as AWS S3, Azure and whatever else is virtually rending a comprehensive and sustainable maintenance almost unfeasible
Just trying to play the devils advocate as so much time has passed since the path type introduction and I feel almost nothing has improved on this.
What is the plan to continue with the path type integration?
Edit: Adding to this I found myself in a pretty annoying situation where I need to restore a path variable with the specific name “temp_dir_path” for session resumption purposes.
Unfortunately, though, there seems to be no chance to accomplish that as all nodes which allow editing of variables do not support the path type and, “adding to the injury”, the only node allowing to create the path from a string only allows to add a suffix.
Hi @mwiegand , I’m with you on the Path integration. As I like writing components, it is a frustration that components cannot be written to accept a path variable as an input field, and instead I have to include a String configuration meaning that in order to use the component, invariably a Path to String is first required. That just adds further nodes to the flow which the component is trying to avoid.
As an aside, one thing to note is that the Variable Expressions node does contain path handling facilities which may be of use:
Meanwhile on the subject of components, it might (not) surprise you to know that I have a component (!) The purpose of it is to create new path variables from old, with modifications and tweaks to the original path
I use it most commonly with the Continental nodes for formatting xlsx files.
Here, the Excel Writer is set to create/pass on a path variable which is the original xlsx file path. The Edit Path Variable Filename component takes the “xlsx-file” path variable, and appends “-fmt” onto the end of the file name, and generates a new Path variable xlsx-file-formatted.
The XLS Formatter (apply) node then takes both the path variables; one identifying the original xlsx and the other identifying the output path for the formatted worksheet. This saves an awful lot of manual conversions and String manipulations for what should be a really trivial operation.
That is a very simple use of the component. It can add a filename suffix, a filename prefix, change the extension, perform a simple regex replacement on the file name, and/or a regex replacement on the folder. Well that’s the theory anyway
Oh, and it can also replace an existing Path variable, which was something I recall being problematic at some point.
You are officially the components guru for me now And thanks for pointing me towards the expression nodes. I recently had setup my entire system from scratch and apparently missed some beloved extensions like that. Worth to note that I created a topic to ease that process of “Knime recovery”.
Since we are at it. I have a component I use a lot that would create the /data/ folder under a workflow and store its full path in a Flow Variable and also determine the path separator depending on the operating system.
P.S.: yes there also is an environment variable for that but this does not seem to work in some cases.
I think many of us have at times had similar needs. There are clearly a huge number of “real nodes” just waiting to be written, lol!
The component I initially wrote for getting quick access to the workflow data folder by opening it in Explorer (or equivalent) “Open File or Folder” was soon adapted to give a path reference to the folder (including workflow folders) or other file as a flow variable, and actually opening it in explorer became optional.
The need for better support of the Path data type has been raised multiple times in previous Star Alliance meetups.
More than two years have passed, yet there’s been no progress on this issue. Constantly converting Paths back and forth—especially when core nodes like Row Filter have been completely revamped—is becoming increasingly frustrating.
no worries, I get the frustration. I can only answer parts of it and will forward other parts to the relevant people.
The row filter was revamped but as we wanted to release it early and iterate on it, we focused on the main data types in KNIME (Number, String,…). We are currently enhancing it so that each data type essentially can provide individual ui elements to allow filtering. Think of a data&time, where you likely want to define a start/end/both date to filter for. This is similar to what you need for a path filtering. A path is not a string but consists of multiple parts (filesystem, url, …) which makes it more difficult to define a filter for it.
These things most of the time look easy from the outside, but turns out to be a bit more complex as soon as you dive into the details and want to support as many use cases as KNIME does. While this makes us slow in the beginning, this also allows for the flexibility that KNIME needs and you likely love
tl;dr: We are on it, some technical details slow us down (at least for the row filter support)
nothing new here, unfortunately.
many implementations since the 5.0 version either lack basic functionality or are replacements with 10% of the predecessors functionality.
Its 2025 and
String Manipulation (Multi Col) still has no column selection by type
Math Operation (Multi Col) still has no column selection by type
String to Date&Time still has no column selection by type
The new Expression node does not support types Path or Date&Time, but Column Expression is already flagged as Legacy
The new Row Filter can’t wildcard filter Path
There is no easy way to combine a Date column and a Time column into a Datetime except for concatenating casted Strings
Lag column can only lag forward (1,2,3,…) but not backward (-1,-2,-3,…)
most of the new nodes (e.g. Value Lookup) cannot use the RowID. requiring you to cast it into the dataset before using those nodes
We had a Date&Time based Row Filter for ages but no Splitter - always requiring a subsequent Reference Row Splitter
There is no Number to Duration node. Column Expression now officially Legacy but Expression node not covering that either
No way to combine two columns of type Duration into one without casting
There is a Parallel Chunk Loop extension but no Concurrent Loop option
Parquet Files cannot be read from \Server\DriveLetter$ paths. Further, encrypted .parquet files cannot be read (or written).
…
as much as I appreciate the KNIME team looking into new and current (AI) topics, base functionalities should always get priority in my opinion.
We hear you, and we are definitely not just looking into AI topics
Regarding the date & time issues that you mentioned, it is exactly as Daniel said before: while it takes us a while to bring features into the modern nodes UI, we try to do so in useful chunks and more consistently than in older nodes.
In the next release, the date and time nodes will have a modern UI, and the expression node will have full support for these types, also allowing you to create and combine date, time and duration columns with lots of flexibility.
If you want to try these features early: most of the date and time nodes with modern UI are already in the 5.5 nightly. The integration of date and time types into the expression node is undergoing a review right now, so probably by the end of next week you should see a lot of functionality in the nightly.
And thanks for pointing me towards the expression nodes. I recently had setup my entire system from scratch and apparently missed some beloved extensions like that. Worth to note that I created a topic to ease that process of “Knime recovery”.