Recovery mode when adding extra columns

1minManager · 02-21-2020 07:27 AM

So I’m updating an App by adding loads of new columns. I made sure the user wasn’t using this table at all and assumed that any issues with syncing could be cleared up by using recovery mode.

Added about 70 columns over 2-3 hours. Now the client has all 3 devices with sync issues. So turned on recovery mode. But it fixed… nothing

All devices where reporting they found 101 columns in the scheme but anywhere between 110 and 147 columns in the spread sheet. At the time the spreadsheet had 148 columns and 4 virtual columns.

How can the all be reporting a different number of columns in the spreadsheet? Its almost like it wasn’t rechecking the spreadsheet.

Anyone any ideas?

MultiTech

Perhaps each app received a copy of the table while you were adding columns;

Joey accessed the app when you had added 30 new columns, hence he see 130;
Mary accessed after that, when you’d added 56 columns, and she sees 156.

Maybe something like that?

But I hear you, recovery mode needs work.

APiCC_Conor

I’ve had similar issues as well and never found a good solution. I try to make sure nobody is using the app at all when I have to add columns. My biggest frustration is that when I add columns to a table that the user is not even using, ALL of their syncs will still refuse to go through.

Recovery mode has never allowed a sync to go through when this issue has occurred.

Bahbus

When doing massive upgrades like this to deployed apps, it’s important to use the versioning controls already in AppSheet whenever possible.

APiCC_Conor

Correct me if I’m wrong, but versioning controls will not prevent column errors if you’re making column changes to a table that already exists in both versions.

Bahbus

I didn’t have an issue when I was adding a column here or there. But the new version became the stable version within an hour, so I may have been lucky. But I also never tried what you were doing. If a column is deleted it will definitely mess up regardless.

You could also use the version control for App Upgrade (right above Stable Version in screenshot) which is more what yours would be specifically. That would involve making a copy of the spreadsheets and app. This would not throw users any errors no matter what you do to the new version.

APiCC_Conor

The issue with the app upgrade is like you say, making copies of apps and tables. Doing that requires that you manage the flow of data from the old into the new. If your users are saving data right up until you upgrade the app, some will still be on the old version and sending data to the old table(s) while others are on the new version and sending data to the new table(s).

Bahbus

No. That’s not how the App upgrade works. No one would be actively using the “new” in process version - outside of perhaps a few testers who should specifically be testing it with fake test data. When you’re new version is done and ready to be pushed to the users, you let them know of the small window for the update, and push the new version to everyone at once.

APiCC_Conor

Yes but if you have people using offline or running on a slow connection, they will still be saving data while others are updating their app and running on the new version. So your previous tables would still be potentially receiving data, which you would then have to migrate into the newer tables since they are now the new versions. Pushing out the new version wouldn’t mean that everyone immediately starts using it, that’s the whole issue.

Our apps build on previous or historical data, it’s not as simple as moving everyone to a fresh empty table. The tables need to also contain the previous data, which is dynamic and always receiving more.

Unless I’m mistaken, even doing it by this method would require downtime or freezing everyone’s input. Unfortunately even if you pause the app, people who are offline could still be queuing up syncs. When you deploy the new version, they will still get a sync error because of the changing of the column structure.

Regardless, duplicating an entire app and all its tables is very inconvenient when using a database. Especially if all you’re trying to do is add some columns.

Bahbus

Downtime will ALWAYS be required in some way shape or form. There is absolutely no way to have ZERO downtime when upgrading software. It. Is. Not. Possible. The point of these is to MINIMIZE the necessary downtime. How you get the point across to your users is up to you, and how you choose to minimize it is up to you.

The upgrade path is still the best path. Make your copy. Make your changes. Test them. You set a time for the upgrade to occur. You make sure well in advance that every user knows about this pending upgrade and that any updates must be synced by this time. Click app upgrade button. Transfer old data to new tables. Let everyone know upgrade is complete and need to sync the app. Eventually delete old, unused data.

The whole downtime only needs to be as long as it takes to transfer the data.

APiCC_Conor

The purpose of this post was to discuss adding columns to tables that were not currently in use by the client. I strongly believe that this is something that could be technically feasible without downtime. Appsheet is meant to operate offline. Downtime of any kind becomes a treacherous path when something like recovery mode is unable to help a user get their queued changes through.

Imagine that the internet goes down for a day at a jobsite that uses Appsheet to track their timekeeping. Now imagine that there was an app upgrade scheduled for that evening. The shift would go home with their unsynced changes queued up to be synced the next day. If the maintenance still took place, any changes to column structure would prevent all those users from syncing, even if their syncs didn’t directly conflict with the column changes.

This is an extreme example, but the point is that offline operations and queued up syncs can make it difficult to enforce downtime in the way you are describing.

Bahbus

Then hopefully you have good bi-directional communication. You told them the upgrade was going to happen. They are unable to finish their syncs due to issues out of their control, so they notify you of the problem ahead of time. You reschedule the upgrade to a different time. Let everyone know of the updated timeline. This is all normal IT workflow for upgrading software.

And lastly, AppSheet is not meant to run offline. It can operate offline. There is a difference.

APiCC_Conor

Recovery mode is explicitly for the for the types of issues I have been describing, where a user is on an old app version and is unable to sync their changes. Your solutions of downtime and extra communication bypass the “what-if” scenarios that occur in real world use. Can you think of any other major app that completely breaks (from the user’s perspective) if they try to access it after having been offline for a time? Normally they will just get an update notification, they won’t be at risk of losing anything they did while they were offline.

Communication and downtime etc. are important and obviously have their place. However with that being said, it will not always happen perfectly. When issues occur it would be nice if tools like recovery mode can help your few poor communicators to sync their app changes.

Bahbus

That is only one use of Recovery Mode.

Generally, no, depending on the type of app, but I’ve seen it. Hell, I’ve seen an app upgrade only completely break users on a very specific device. But those “major” apps, aren’t being built on a no-code platform. And the even ones that would break, absolutely require online access in order to use, so they force you to update to avoid the issue.

Nothing happens perfectly in this world. We all know that. But Recovery is for when the unexpected happens. You adding columns to the database that the app is actively looking at is not unexpected. Your users may think so, but their thoughts don’t matter in this.

So, use the tools that do exist to minimize the downtime to as little as possible. Use recovery when the unexpected happens. Either way, Recovery is a manual process and will probably stay a manual process.

It all comes down to planning.