This is a topic that I’ve raised among my senior-dev peers, but there doesn’t seem to be any real solution. It seems like a huge shortcoming for Bubble, stemming from its lack of true looping in BWFs and use of recursive looping instead.
Let’s look at a concrete example: (All of this is predicated on the notion that we can achieve it without additional DB state/status tracking.) We may need to generate a new record with data from a lookup for every permutation of shirts’ X sizes and Y colors. Keep in mind that we won’t know if we will create the record, and what data it will include until the ultimate lookup. So, loop1 will iterate thru X and for every X, it will call the nested loop2. Loop2 will take the X it got and iterate thru every Y. For each (X,Y) it has, it will do the lookup and create the record only if the conditions deem it necessary. HOWEVER: In addition to calling loop2, loop1 will also iterate itself using the only way it can in Bubble: recursively rescheduling its own BWF with X-1 until it has exhausted its X input,. But it will do this irrespective of what’s happening in loop2 - it’s doing it asynchronously instead of synchronously within the context of its nested loop. Hence, a capacity pandora’s box. Now, augment this example with our actual case, where we have 5 such nested loops for additional attributes like shirt style, fit, and cut. (And BTW, we’re already spacing out the re-schedules by several seconds, which translates into many minutes for the process to conclude if we’re dealing with several thousand permutations and records created).
So: How do we achieve nest loops where each child loop must execute in its entirety before the next iteration of its parent executes and address the capacity ails we’re seeing in larger apps depending on this type of feature?
