Hi, I’m revamping a massive knime workflow and I’m wondering instead of reconfiguring one by one, is there a way to automatically update subsequent nodes (e.g. groupby) that use that column to the renamed column name? Thanks!
1 Like
@Ngoi_Qi_Yin welcome to the KNIME forum.
I do not think there is an option to change all the times the column name is used at once.
Is it possible to use the old name in the WF and just rename at the beginning and the end and document this in a note?
The only other option would be the use of shared components or meta nodes.
3 Likes
I see, ok thanks for the advice!
1 Like
I moved this over to Feedback and Ideas since it is not currently possible, but it is hard to imagine a more useful KNIME capability then to have column name changes automatically applied to downstream node settings and formula references.
It would dramatically reduce errors and simplify workflow adjustments, process portability and adapting existing flows to different input file structures. No clue how feasible something like this would be, but it would certainly be amazing!
3 Likes
@takbb / @qqilihq / @danielesser
I tagged a few of you that seem to have experience manipulating node code via automation. I wonder if this is possible on the user side… Is there any feasibility to the concept of building a column name re-map and then running a KNIME workflow that performs a find and replace for column name references in the setting.xml files of another workflow? It seems like it might be possible to do a universal change across all nodes if the settings.xml contains all of the column name reference code, but I am wondering if there might be any way of identifying the order and list of downstream nodes for a more targeted approach? Perhaps if the effected node ID’s were identified by looking at errors in the log files?
1 Like
By the way, ask a question, do we have any spec about settings.xml or we have to learn it from source code?
Hi @iCFO, one answer to that question can be found (if time/inclination permits) in this rather scary workflow:
It’s scary for a few of reasons:
(1) it requires python install (using the now legacy python nodes, but won’t work in beyond python 3.9 and above because of removal of certain methods (I’ve just downloaded it and tried it with python 3.7.8 in KNIME 4.7.8 and it works there, but no guarantees about later releases)
(2) It attempts to process the workflow.knime xml file, which I haven’t seen documented, and so it is based on manually working out what was going on at the time, and so may (or might not?) change with KNIME 5.x
(3) I wrote the workflow just under 3 months after seeing KNIME for the first time, so there may well be a lot of newbie mistakes in it
However, contained within it is the ability to produce a list of the nodes contained within a workflow, and identify for each the previous and next node, and the port number from which the join was made.
I may well revisit this at some point (but not today! lol) to see if it works with KNIME 5.x, and update it so that the python code (in a component used in the workflow) can be updated to work beyond python 3.8.x.
As an idea of what it produces when it executes, the above workflow simply reads its own workflow.knime file. This is what the workflow looks like:
And the output is this:
Additional notes:
2 Likes
This is great! I will see if I can get around that Python package dependency when I get an opening to tackle it. Thanks!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.