Synchronization that recalculates all real columns

[Gustavo_Eduardo]

While working with my app I was thinking, sometimes we nest actions in Grouped: execute a sequence of actions. Thus, several actions are executed at the same time. I imagine that synchronization is similar to a "read the data that has changed in the database and display it in the app interface" action.

I was thinking "how useful it would be if there was a configuration option in the app that allows data synchronization, at the same time, to recalculate all the real columns of the app, impacting the data in the databases", that is, function as a nested behavior action, as if it were synchronization grouped with base recalculation. This would save many virtual columns and, in addition, production time, since many fewer actions and bots would be necessary to recalculate "every time there is a change in a table" for example. Since it is not convenient (perhaps for some people and in large apps) I propose that it be a configuration that can be activated or deactivated using a button from the app configuration from the tables themselves, so that the developer, with a button, can include the table or not, within this "massive synchronization". Clearly I am a dreamer and probably in the eyes of those who really understand programming it will even be funny because they will understand that I understand very little; I simply raise this from my place as a "user" and at the same time as an "app creator".

[Rifad]

While the idea has merit, there's a concern about delays due to synchronization overhead. In contrast, the AppSheet API is quicker for extensive updates. A practical approach might be a system where each row automatically updates an [update count] plus one, in tandem with a sync button.

Another suggestion is to incorporate actions within the sync button. This could involve grouped actions that are triggered either through a manual click on the sync button or by automatic synchronization. Such an integration would significantly streamline the synchronization process, allowing for more tailored sync behaviors and ensuring consistent app performance.

Despite these ideas, my current outlook on AppSheet's management is rather pessimistic. Although AppSheet is inherently a solid product, its potential seems hindered by the present management team's lack of attention. Should there be a future shift in management and the development team, these suggestions might prove to be exceptionally useful.