Yes, that’s it. @bruno29a has understood also the problem. Hope you can help me as I still have not implemented any recursive loop
Hi @jquadrada
Please find below a possible commented solution:
and the workflow:
20210929 Pikairos Top parent hierarchy search.knwf (74.2 KB)
Hope this helps.
Best
Ael
I give it a look tomorrow and let you know.
Thank you
My pleasure
Best
Ael
Hi @jquadrada , I’m back. I see what @aworker has provided solution, which is good enough.
@aworker , originally I had wanted to use H2 as a virtual table that would allow me to set some values and update them within the loop. It looks like it’s no necessary based on what you did
Hi @bruno29a
Thanks for your help here. I’m always impressed by your solutions to so many different KNIME questions!
Sorry, I did not understand what you meant here by “to use H2”. Could you please develop ? May be you could add here this alternative solution too.
Best
Ael
Hi @aworker , thanks for the kind words.
Regarding your question about H2, manipulating values in a table and keeping these new values within loops in Knime is quite tricky, so my idea was to use a virtual db table instead where I could update values in the db table at every iteration of the loop, and H2 is the best way to do this as it can generate the db connection and create a table in memory.
However, with the Recursive Loop, it was not necessary, since the Recursive Loop allows you to pass on the “new” values to the next iteration.
Hello there!
How about simply a Cell Replacer within Recursive Loop? Also stop criteria is probably a good idea so you don’t have to run large number of iterations to be sure you’ll find parent.
Here is workflow:
Top parent hierarchy search_ipazin.knwf (31.5 KB)
Br,
Ivan
Hi @bruno29a
I understand now. Certainly a possible alternative. Thanks for the explanation !
Best
Ael
Hi @ipazin
I had never used the -Cell Replacer- node so didn’t know about it. Very useful to know and certainly the best solution. Thanks @ipazin !
Best
Ael
Tnx @aworker and @bruno29a!
Cell Replacer is really useful and one of my favorite nodes. And if once gets improvements like wildcards and regex it will supernode
Ivan
Hi @ipazin , indeed, I can see that. Like @aworker , I’ve never used it before. It’s a very useful node.
@ipazin Just a comment about the loop stop criteria. Your recursive loop stops at a fix arbitrary number of iterations which is larger than the number of rows. The number of rows is a better upper bound since the loop should not iterate more than the number of rows (i.e. the number of nodes in the graph). This is still an upper bound which could be lowered to the minimum number of iterations. This can be done using as condition that the LevelUp column had not changed compared to its previous values, as follows:
Could the condition checking be implemented with less nodes ? Please suggest. I’m curious
Best
Ael
Hello @aworker,
the number of rows is indeed better upper bound if not building stop criteria. For a stop criteria I was using similar approach and needed 4 nodes but had different workflow design (no Rule Engines outside loop and one Rule Engine was inside loop to give entire path which led to parent) which allowed me to aggregate on last column to count missing values and stop based on it. Your approach seems better. Alternative that comes to my mind is as always scripting…
Br,
Ivan
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.