Hi Knime Team! It happens to me a lot that I have to find a node in a large model only knowing its ID (the IDs of my nodes usually look like: 43:507:169:46). It is very painful to find the node in Knime only by browsing, opening submodels (wrapped metanodes and normal metanodes) and visually identify the node in the workflow. Is there a “search a node by ID” option in Knime? (I googled a lot without success). If not, is that feature on the Knime’s development roadmap? (By searching a node I mean to focus that node in knime workflow window and bring it on the center of the screen).
Bonus part 1 (additional search option):
By the way, searching nodes in the model by another term will also be very interesting and useful, for example an option like to “list all the nodes containing th word XXX” somewhere in the title, description, variable, code or calculation, etc. Is it possible?
Bonus part 2 (Auditing columns more easy)
One last very useful option will be the option to “list all the nodes that touch/use X column somewhere upstream in the workflow” (with that option will be much more efficient to audit the columns calculation done somewhere upstream in a model). Any ideas if this will be possible in a near future? Does anyone know a workaround for this?
A colleague of mine came up with maybe a similar question and we developed some super dirty approach that might give you an idea where to look.
Since all things KNIME are stored in XML files we thought we might as well import them and search for a specific term.
I constructed this scenario. I have my XML search meta workflow and a workflow in a subfolder (you might use any folder you like). I want to know where someone used the term “cryptic_xy_name” somewhere in the folder/workflow.
And indeed there it is. Someone used the term in the Body of Java Edit node #2.
Please note: since this is quite dirty it might take a while and if you search for very generic terms you might get very large result tables. But you could explore them further.
Thank you very much @mlauber71 for your “dirty” solution. Your proposal will be useful to my bonus part 1 and bonus part 2.
However, my main request (before bonus part 1 and 2) still there. I mean: I don’t see an easy way to find where is located a node with ID XX:YYY:ZZZ in the screen (Window with knime model). Does anyone know a workaround for it? Is there a solution in Knime’s developing plans to avoid the task to visually finding nodes when you have a very large model (with hundreds of nodes)?
Just to show my point, let’s put a real life example with one of the models we are working on. Suppose our goal is to find the node with ID 2:507:361:0:329:283 (For example I got that id because there is a warning in my logs that affects the node ID 2:507:361:0:329:283). Opening the metanodes #2 and #507 was easy (not many nodes on that level). Now the next step is to make a click on metanode #361. But where is that node? Can someone find it in the following screenshot?
The last screen! We are done with the example! Did you found node #283?
We get a lot of warning on the log saying that Node with ID XX:YYY:ZZZ is having problems. Can you imagine how painful is to go through the log solving all the issues if we cannot go to the affected node easily?
I’d love KNIME team considered the “locate by node ID” feature in this excellent software! I hope that day comes soon! (Meanwhile, more workarounds are welcome!)
When the search function is in place I suggest as further bonus to enhance the KNIME Console. A double click in a line of the console could focus the node which emitted the warning or error.
I had have the same problem for weeks. My workflow have about 700 nodes and finding a node takes a long time. When will you implement /develop this improvement?
It doesn’t really solve your problem, but I just want to mention that the Linux/MacOS “find” command line utility can help with locating nodes. Earlier today I used
find . -name '*Recursive*' -print
in the workflow folder to find in which metanode the recursive loop was hiding.
Very helpful, indeed. The problem is that it doesn’t seem to search recursively into lower-level metanodes or components. This severely limits its usefulness in complex workflows.
