Hi @bruno29a
I understand now. Certainly a possible alternative. Thanks for the explanation
!
Best
Ael
Hi @bruno29a
I understand now. Certainly a possible alternative. Thanks for the explanation
!
Best
Ael
@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