Hey all,
I have an orders table. Each row in the table has a priority that’s manually assigned. I’m trying to allow the user (or later, an action) to reassign priorities. The strategy is:
The way I’ve implemented this:
count(select(orders[priority], [priority] < [_thisrow].[priority]))*2
Select(orders[key], [priority] <> "")
Referenced action: Set priority for this row.I’m having problems running adjusted priority for many rows.
It works fine for data sets of 15 orders. It’s bearable for up to a couple hundred. But as soon as you get to 500+, it causes Appsheet to hang and chrome to tell you the tab has become unresponsive. I’ve put this into a totally separate app, so there’s no other actions / workflows / dependent tables getting triggered.
It seems to me like this should be a linear algorithm. Yet, it seems to kill appsheet on relatively small databases.
Why is this so brutal?
How should I do this?
This:
On sync, each row of Orders scans all rows of Orders. O(N**2)
This expression doesn’t do what you think it does. Read more:
Thanks, Steve. (Also thanks for that bonus tip on the operators!).
When does Appsheet trigger a sync? When I sync the app, the delay is 5 seconds. When I run adjusted priority for many rows, it delays 25 seconds, then the chrome warning comes up about the tab not being responsive. Is it synching on every single row change for an action on multiple rows?
Sync is unfortunately an overloaded term. When you tap the circular sync button in the upper right corner of the screen, the resulting process does three things:
Copy local data changes to the server for storage in the corresponding data sources and potentially triggering workflows.
Download and install any app configuration updates.
Download current data from the server, including recalculated virtual column values.
Any time you see that distinctive “Syncing app” screen, this process is underway.
Part (2) is what really disrupts use of the app. Parts (1) and (3) actually occur automatically behind the scenes even without an explicit sync whenever there are local changes that have not been sent to the server. After you make a data change, you can observe (1) happening as the number in the orange/red in the sync button counts down, once or each update is sent. Step (3) occurs after all individual updates have been sent. You’ll know (3) is completed when all of your virtual column values magically update at once. The time it takes is entirely dependent n the amount of data and (more importantly) the complexity of your virtual column App formula expressions. If the app user males no data changes that would prompt step (1) and (3), the app will automatically attempt step (3) every 30 minutes or so while the app is open.
So the term “sync” may refer to the entire three-step data+app sync process, which is disruptive to the user, or to the steps (1) and (3) data-only sync process, which isn’t disruptive.
In your case, you notice different sync times. Some sync time variation is normal, typically within just a few seconds. The vast difference you’re seeing is probably due to the workflow. In that case, the sheer amount of processing required to complete the workflow adds a great deal of time.
User | Count |
---|---|
42 | |
25 | |
24 | |
19 | |
15 |