Solved: Can sync conflicts happen with row edits from API ... - Page 2

billyfw · 08-30-2022 01:49 PM

Hey guys -

I've been trying to take to heart the idea that my gsheet backend shouldn't update any data directly that is being used for an app, and thinking through a design for how to have my gSheet run a bunch of code to calculate a handful of very complicated field updates (more complicated than I want to implement in AppSheet - maybe impossible, i'm not sure), and then send the edits to the app API.

So here's my question:

If I use the API to call edit for a handful of rows and change some field values, those edits are made on the server (not my app client), correct?

If so, what happens if, prior to a sync happening, the app user changes a value which was also changed on the server by the API call? And, is there a way to prevent this? How should I think about edits via the API (and ensuing syncs and data consistency)?

Thanks much,

Billy

PS-An example chain of events to illustrate my question:

1. App API is called to edit the Middle Name field on Billy W row from Smith to Johnson.

2. Prior to the next sync (because the app is offline or just timing or whatever), an app user manually changes the field from Smith to Jones.

3. A sync runs, and the server row has middle name Johnson, but the app has middle name Jones. Sync conflict? What happens and is this preventable?

Thanks everyone!

WillowMobileSys

What happens if two edits are sent to the server at nearly the same time? There is NO Sync conflict....Last one in wins.

How can you prevent this?

Technically speaking you cannot prevent it in a systematic way. AppSheet is a distributed system meaning that each "device" gets its very own copy of the data. Changes are made by a user oblivious to what any other users are doing. Edits are then simply submitted by the client and applied to the data - no inspection of any other edits being made is performed.

The good news is that most apps are segregated such that two users making changes to the same row at nearly the same time is very rare.

But if your app is one where changes by users frequently collide, there would need to be either some restructuring of data to make it less likely for a collision OR change in user procedures that make it unlikely two users are updating the same row.

For example, maybe a table has a large number of columns and different users are typically changing certain areas of the rows creating some logical division of the row. You could divy the table by the logical areas into 2 or more tables then users would be editing different rows in different tables preventing any collision.

Another example might be assigning areas of data responsibility. Employee 1 changes orders for clients A-M while Employee 2 changes orders for clients N-Z.

View solution in original post

Can sync conflicts happen with row edits from API invocation