I often find that I want a bot to trigger on both newly created records and/pr when a specific column changes. The former can be done by choosing “Adds” or “Adds and Updates”. The later by using [_THISROW_BEFORE].[ColumnName] <> [_THISROW_AFTER].[ColumnName].
The issue I’m wondering about is can I combine both of these into one bot? Since I’m sure in the past I’ve used “Adds and Updates” with [_THISROW_BEFORE].[ColumnName] <> [_THISROW_AFTER].[ColumnName] but it didnt trigger on Adds because as far as the bot is concerned [ColumnName] was created but it didn’t change.
@Suvrutt_Gurjar suggested expression is the only way I know to do this. I have never understood why AppSheet doesn’t just surface the row edit state. They clearly know if a row is NEW or an UPDATE in both Forms and Bots. I highly doubt they re-query to check row edit state - I suspect there is a variable there used by the system…just surface it to us App Creators.
Anyway, in absence of such a variable, I would recommend to keep the Bots separate for efficiency unless you have some compelling reason to combine them.
If the Bots are separate, the ADD Bot can quickly dismiss the UPDATES and the UPDATE Bot can quickly dismiss the ADDs. In other words, in 3 operations the system knows if it needs to execute the ADD Bot, execute the UPDATE Bot or neither.
With a combined Bot, it will need to potentially inspect each row of the Table to determine if the Bot should run or not - on EVERY row edit. As the Table grows, so does the length of time to determine if the Bot should run.
Thank you for your valuable inputs. Those are thoughful and detailed as you always do.
Your point on each row evaluation is indeed worth considering. I agree that a row level evaluation can be expensive and should be avoided.
In this regard, if I may mention one point that I have a feeling that all inclusive lists such as Table_Name[Column Name] or Slice_Name[Column Name] seem to execute much faster as compared to list functions that take arguments such as SELECT() or FILTER() .
Even expression assistant does not flag an all inclusive list with a standard warning that " this expression could impact the performance." For any SELECT() or similar functions, the assistant gives that warning. I think this absence of warning for all inclusive lists would be intentional.
At this moment, I do not have any calculation base to support my statement. Today entire my day and tomorrow, I am away from my work desk and responding from mobile while in transit in travel. But when I am back at my work desk, I will carry some tests and revert with my readings. I will of course carry the tests on VCs on large tables.
I believe what you are referring to is Indexing. The question is if AppSheet employs Indexing on the app side of things. More importantly, does AppSheet take advantage of Indexing in the IN() function. I don’t know the answer.
Thank you. I had list compilation time in mind - the list used in IN() function as that is a multirow expression. . Maybe I misunderstood you. I am now trying to understand your below referred guidance.
Could you guide which part of the suggested expression will start consuming more time with increased table size?
The IN() function , or the next [_THISROW_BEFORE] …[_THISROW_AFTER] based comparison or both?
