Concurrent use in AppSheet. Undocumented Slices solution. Vs promise of no-code platform

[pbalerio]

Hi everyone,

I want to raise my concern about the management of concurrency and open the debate.

I think that this lurks behind nice debates in this forum, such as the impossibility of sequentially number records with confidence, ‘ghost’ changing rows values and many others.

Coping with its results is a reason why AppSheet has not achieved to be “no-code”. It differentiates the true experts from the advanced users.

The problem: “Last sync wins”

• two users open the same record, in two different moments:
  let’s say an invoice, User A opens it with status OK and User B opens it with status “to process” (one step behind)

• User A decides to pay it and after that, User B decides to authorize it. Invoice is paid and then changed to be paid again.

That a typical sync changes the full record is partly to blame to this behaviour.

UnOfficial Solution (using a partial slice)

With a Form that points to a Slice, which only has some columns, AppSheet changes behaviour connecting to the server.

The JSON sent only contains those columns. Hence AppSheet engine ‘tells’ the background data-persistency platform: “Just Update these 3 cells, don’t touch the rest of the row”

More: Actions and in-line edits do the same.

ToDo (AppSheet Team please):

I did not find any documentation in AppSheet describing this.

Loosing the No-Code essence

Solving the concurrence problem, common to all multiuser database applications, is, in AppSheet obscure and little documented beyond the community.

I think it is something AppSheet has to solve: Either document it prominently to all users, or ideally, implement a native mecanism (maybe a field in colums and forms) that maybe by default all forms’ fields are sent but perhaps by alternate behavior only changing columns are.

New users don’t have easy access to this information.

Note: I am not supporting record-locking!

[Steve]

The updates should be done in a child table, which then also functions as the change log. The parent record should contain the current value as indicated by the child table. If the child table receives an invalid entry, a bot can catch and handle it.

[WillowMobileSys]

I do understand where you are coming from.

A system, any system, cannot solve concurrency without some locking capability. AppSheet does not have locking mainly because it is a distributed system that supports “offline” mode - each user gets their very own copy of both data and app. There are cases in a distributed system where locking would be ineffective so I imagine that is why it has not even been attempted (or maybe it was attempted and just didn’t work).

However we, as App Creators, CAN avoid conflicts from concurrent editing by implementing:

1. Process - specific rules in the way users interact with the app.
2. App Design - driven by the knowledge of how multiple users are editing the data. The goal is to minimize possibility of row clashes by segregating data into other tables - which is similar to the “partial slices”.
3. BOTH!!

You are encountering the issues because your apps and development needs are becoming more sophisticated. You also need to increase the app-design knowledge to match. App Creators need to adapt to the capabilities provided by the platform and make compromises to achieve their goals - that’s true for ANY development platform.

None of this affects the no-code/low code aspect. No code does not mean “easy” and it certainly does not mean “comprehensive”. No code platforms were never meant to be an app all-inclusive tool.

I do agree that documentation and examples don’t cover some of these more complicated implementations. But honestly, they simply cannot create documentation on every conceivable way an App Creator might build their apps. That is where the Community and off-platform support sites might become helpful.

(NOTE: For your “partial Slice” discovery, you can open the Slice articles in the knowledgebase and request that they update the article with details about how updates to rows work for these partial Slices. I actually forgot about this “feature” until you mentioned it here.)

AppSheet is not perfect and never will be. It is one of the best low-code platforms out there for its intended use mainly because of its flexibility. With that flexibility comes complexity that tends to steer it away from a pure no-code environment.

Lastly, a little pet-peeve of mine….dozens of people attempt to use the inability to support sequential numbering as a measure of the “quality” of the platform. It’s not. Sequential numbering is an archaic technique that is irrelevant in today’s technology. There other ways to obtain the same VALUE that are more comprehensive and flexible.

[Suvrutt_Gurjar]

Well articulated @WillowMobileSys​