Fast loop strategy creating many child rows (using bots)

[luizluca]

I've been using different strategies for creating a loop action in appsheet mostly based on the same logic as in https://www.appsheet.com/template/appdef?appId=LoopingwithActions-96620&appName=LoopingwithActions-9...

1. Using a temp enum list field in a source table
2. In a grouped action (source table)
   1. process first element (i.e. creating a child element in another table)
   2. remove first element from the list
   3. recall grouped action if list is not empty.

However this increases the backlog when the action happens quite fast as the number of items increase. I tried to move that sequence to the backend (using bots) but, although fast, it easily break the time or recursion limit and it breaks with a couple of dozens items.

I created a different strategy that others might have already used but I didn't find it yet here. This is the reason for this post.

I create an "Iterations" table with only a single "i" column with each row being a number in sequence (1, 2, ... N).  It will be used to paralelize the action process. When I need to iterate over an enum list, like mylist, and create child items in a second table, I use the "Run action on rows", filtering the "Iterations" rows with:

[i]<=count([_thisrow].[mylist])

calling an action "Data: add a new row to another table using values from this row" for the table Iteration. The main issue here is that you cannot use inputs in this kind of action (I already asked google using a feedback form to add that feature) and you need somehow to find the source list inside the action in the iteration table. Normally, you'll have to check the source table for list that are not empty (if the list is temporary) or something else like the last change row from this device (combining the device context (context()) with the timestamp when the row was saved). Another option is to create a second "transactions" table that you can use to store the device, timestamp and the list related to this action.

If you run that action in the user context, it will be fast but it backlog being written to the database will still be equivalent to the classical loop using the grouped action. However, if you move that action to a bot, it will be almost instantaneous, even with hundreds of child elements.

I could create an example app but I guess it would be better documented if implemented in one of those existing loop-action examples.