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.
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”.