Have an app with a Google sheet as the user profile sheet but it is incurring too many updates so need to change it to a native table. I have reproduced the table, including all columns, relations etc and know how to switch it to the source.
The issue will be connecting all the columns that are used throughout the app to the new table. How do I go about this? I’ll have to switch the source first but don’t want to interrupt users as I go through all the UI components that need the user table to function. Can’t see any way of doing it that would not require the app going offline for a couple of days. Is there a recommended way of doing this?
Ideally, I would go though and connect each component to the new user table before switching the source while keeping the old user table intact until I know it works. But this is impossible because we can only have one active user table.
I would duplicate your users table. To do that from a Google Sheet Table, follow this procedure:
Go to the data editor in Glide.
Right click the Users table (the one linked to Google Sheet).
Export
Click on the + add table button.
Import
Upload the CSV you downloaded. It will create a new table.
Recreate your none-basic columns in the users table.
It is sure that you would have a short/medium down time since it needs maintenance to switch UI and other tables pointing to the users table. I would suggest you to schedule a maintenance date and alert your users about that. I would also suggest you to choose some users that would like to help you testing things out after the migration.
The day of your migration, you can unpublish the app. Do your changes and publish again.
Then test the app with your testers.
When you are done, just alert your users that the maintenance has been completed!
If you want to minimise downtime, you can make the change in a duplicate of the App, and then once you are done replace the original App with the duplicate.
Start by making the duplicate (keep same sheet option), then create (or link) your new Users table in the duplicate. As Maxime suggests, export/import is a good way to quickly create all your non-computed columns. Make sure you go through every column in the existing Users table one by one with Find uses, and reconfigure all references. Hide each column once you are done with it so you don’t get lost. Then once you are done, unpublish the original App and replace it with the duplicate.
Some of the points I made in the below topic may also apply in this situation:
Thank you, I have already duplicated the table so it’s just a matter of pulling the trigger and making it the new source. It’s a bit scary and I can’t help thinking I’ll break the app as the user table is woven throughout just about every part of it
Thank you that’ll be a great resource. The hiding columns idea is a good one, I was wondering how I’d keep track of everything. It’s going to be a big job but will be worth it in the end
From my experience with any kind of go live in technology infrastructures and softwares, small of extremely big go lives, here are some advices I can give:
Migration are always scary when you are not prepared.
Don’t go too fast. Take your time and don’t “think” it will work.
Be prepared. Document more than enough.
Do a written simulation. For each step, think about what could possibly happen. Write it and build a tree of issues that you could potentially face. For each issues, find solutions (I suggest 2 plans in big case, a backup plan is always helpful).
Don’t stress. You do more mistakes when stressed.
If possible, ask someone to be with you. Two brains, more dimensions.
Today is working fine. Tomorrow can break. Backup very often.