Action writing table title - data takes round trip

[Stephen_Ehmann]

Using inspiration from https://community.appsheet.com/t/dynamic-view-name/14220

Setup:
I have an action A attached to a column in table X that is a grouped action with sub-actions B and C:
B) write a text field in a table Y for storing “titles” to include information about the selected row
C) “go to another view within this app” which is a Table view of another table Z. This Table view has “Display name” set to a lookup in table Y to retrieve the “context sensitive title”.

Problem: select action A, B queues up the write to the server, C gets executed and we enter the new view immediately. However the view’s title is set to the previous setting. After a while the write goes through to the server and is synced back to the app at which point the title changes.

Desired solution: have the application’s copy of the data change immediately, and let the write sync to the server in the background

Higher level question about reasonable expectations of writes: I expect writes to show up immediately on the client side when made to any table. These writes should affect all formulas and expressions immediately. Writes are flushed to the server in the background. I am not trying to get at how it currently works but rather how should I expect it to work, ie. what is considered correct functioning. Are my expectations about correct functioning reasonable or is there a reason why they are not reasonable, please explain?

This FR is also about round trip writes affecting the UX: https://community.appsheet.com/t/form-saved-data-takes-round-trip-before-details-view-sees-it/41156 which I have initiated a repro case with support@appsheet.com about.

[MultiTech]

This is indeed one of the edge problems with AppSheet.

One way I’ve gotten around things is to manually force an update to records that I need data in immediately.

Quick Update System - How to update records in your app with a push of a button Tips & Tricks 💡

“How can I update a parent record when a child record is changed?” “How can I mark all the line items in an invoice as paid when I mark the invoice as paid?” “If I have App Formulas inside a physical column, how can I get those to update like a virtual column?” “How can I recalculate formulas with a push of a button?” All of these situations can be solved by implementing a Quick Update System inside your app. What is the Quick Update System? A way to update app formulas and recalculate v…

---

Stephen_Ehmann:

I expect writes to show up immediately on the client side when made to any table. These writes should affect all formulas and expressions immediately.

Think about the performance impact of this:

• So immediately you want the app to go through every formula again and recalculate everything? Every time new data is introduced? Every time? All the time? For every formula and row?

Probly not; most likely only in a few situations that are specific to some flow you’re trying to capture.

---

This is something that I’ve had tons of intimate discussions with the developers about over the years; many of which you might be able to find in the community somewhere. It’s always been an issue, something that they’ve been balancing this whole time.

[Stephen_Ehmann]

I will read through the suggested article, thanks for sharing it.

Sepaking as a 20+ years in industry computer engineer, I would say that yes, I would expect that all fomulas are resolved immediately (or with some small batching delay) on the client-side. I imagine that there is some dependency mechanism to only update what actaully relies on the change. It already does this when it syncs. Updating formula evaluations on a local machine with no network access should be fast in most cases.

So instead of the serial path:
A) client-write (immediate), server-write, client-read, client-update formulae
I want to know why these processes cant run in parallel:

1. client-write, client-update formulae
2. server-write, client-read, client-update formulae

Is there any documentation of how the data flows between the application and the cloud?

[Stephen_Ehmann]

@MultiTech_Visions do you know if anyone has ever asked to write to a Virtual Column as a way of implementing client-side-only data? The formula is required, but if I could set a VC to a value in an action that would solve this entirely.

[MultiTech]

Stephen_Ehmann:

I imagine that there is some dependency mechanism to only update what actaully relies on the change.

I don’t know the specifics of these things, I’m only a user of the system, but they’ve mentioned things like this.

One particular things stands out that they said back in the day:

• It’s all about how “tight” the connection is with the data.

First level connections typically update

• ie. I create a record in a child table, any dependent columns in the parent update afterwards.

The problem you’ll find is that if you’re trying to get at data from somewhere further away than a direct connection; that’s when you have to wait for the system.

• It’s in these instances that I implement the quick update system.

Anytime I need the results of a formula to update, but it’s not directly connected, I’ll have to create a Ref Update action to force the corresponding record to update.

For example

---

Say I’ve got a list of projects, each with a child level of tasks.

• Let’s say I’ve got an enumlist of the required tasks on the actual project level (as a physical column).
• From this list I can subtract all the completed tasks - giving me the remaining tasks to be completed.

As I complete tasks, the formulas on the project will update.

Now let’s say I pull that value into the Client table through a dereference of some kind.

• As I complete tasks, if I view things from the Client table it will lag behind; this is because the Client table isn’t directly connected to the tasks table in a direct way like they are to the project’s table.

If I wanted the lists on the client to update, I’d need to update the Client table (with the quick update system) - this forces everything to reevaluate.

It’s all about how directly things are connected.

If I need something to show up somewhere, it’s either:

1. Create a direct connection with a reference of some kind;
2. Find a way to update the record (so it grabs the most recent data and updates manually); or
3. Brute force it - which will work (brute force always works) at the expense of performance.

---

[MultiTech]

Just as an aside: you’ll have this same problem (with the data appearing to not update LIVE in the app) with any data changes made through Workflows and Automations.

• Action data changes are the only way to get client-side updates to work.

[Stephen_Ehmann]

right, all the actions I am referring to are not in workflows nor automation nor reports, I am aware that those run server-side.

[WillowMobileSys]

Stephen_Ehmann:

C gets executed and we enter the new view immediately. However the view’s title is set to the previous setting. After a while the write goes through to the server and is synced back to the app at which point the title changes.

When executing actions on client side, it is indeed the case that those changes are available to the app on THAT device immediately. I rely on this behavior all the time for computations and other record updates that I want the user to see immediately. Virtual columns are delayed due to Sync required. Therefore, I avoid VC’s when I need updates to be available right away. Instead I will introduce additional actions to re-calc any values dependent on my recently updated/inserted values all for the sake of that user being able to see them right away.

I consider what you have described as a bug. I would recommend creating a small test app demonstrating the problem and submit it to Appsheet support.