Question on Staging for Apps & Backend bulk data update

Hi Experts,

I have been seeing few very interesting posts over the last 24hrs regarding new features in staging. That prompts me to ask this question about Staging for Apps.

Question1:

Is there an option wherein you can keep the copy of changes that you do to an app in staging and then push all changes to a production version of the app in one shot? because one might want to test or set up relations or have new screen elements etc but don’t want that to interfere with what the end-users might be seeing in live? Is that option available or planned to be introduced probably for Pro apps? I saw a reference to one such thing a few weeks back by David but not able to fish out that thread to read more details.

Question2:

Now the second question is regarding bulk data update from the background. If at a future date we introduce a new column into one of our sheets and the value in this will be dependent for a relation/lookup etc - is there a way to bulk update the value from the backend for existing records at that time? If so how?

Thanks for the response.

-Shiv

The short answer is no. Staging mainly exists for Glide to provide a “sneak preview” of upcoming features, and elicit feedback from the community. We are explicitly advised not to build production apps in staging…

The Insiders instance is only for testing. Don’t build production apps there. We might break or even delete them.

Maybe I’m misunderstanding your question, but this is a non-issue. If you add new data to a Google Sheet, then any/all calculated columns in Glide will recalculate (for all rows) as a soon as the data syncs with Glide. In one of my apps, I have about a dozen sheets that get completely emptied (apart from the header rows) on a weekly basis, and several hundred rows of new data added. The corresponding Glide tables have dozens of computed columns based on that data, and everything Just. Works.

I just re-read your question (just to make sure) and I see you specifically mentioned adding a new column. Again, this isn’t a problem. Once that column syncs with Glide and you start adding computed columns that refer to that new column, then those columns will compute for all existing rows.

Hey @Darren_Murphy

Let me rephrase few statements so that i can be more precise on my question.

Now for Question1

What i am refering to is Staging option for Apps and not the features in Glide. The latter we already know exists and know about all the clauses. So my scenario is like i want to add or remove features every 3 months and they are multiple changes than just adding a screen or building and displaying a relation. So can i keep the changes in one intermediate (staging) setup so that on the given day i can merge the changes into what is on production in a click of a button ?

Now for Question 2

The type of changes i meant are like adding columns to sheet which have “metadata” based on which relations/filters or similar needs to be calculated. Eg Assume i have a setup which has about 200 users already but now i decide to add a column called UserRole - after i add this i would have ensured that i will populate this value via the front end for future entries, but what about the values for existing 200 users - how do i bulk update the values in the column ? Kind of in technical terms am talking about an “Update Query” to bulk update a column based on a condition.

-Shiv

1 Like

For you second question. If it’s a google sheet, it would be pretty easy to copy/paste a role to all existing users. If it’s a glide table, then you would have to manually enter the role in each row individually, or create a screen with an inline list and an action that would set the role column. Then you just rapid tap through all of the users to populate each one with a role via that action.

1 Like

To make it easier, I usually add a boolean column to the process and hide the row after the set column is completed.

1 Like

Thanks @Jeff_Hager Yeah thats the link i was looking for. I used the word staging in search instead of iteration and hence it was not showing up. Thanks for that.

Regarding your other reply - was wondering if there was a easier option to update irrespective of Sheets or GlideTable. If the data count is less then fine if its large then i dont want to end up messing something.
Having said that is there a way to revert if something breaks if its a pro app ?

-Shiv

There’s really no way to mass update data other than manually, in the sheet, or some sort of maintenance screen or app. Glide does not update more than one row at a time. If you set it up correctly with an inline list like I mentioned above, and like @ThinhDinh said, hide the row once updated, then it be pretty easy to mass update rows without missing anything. If you really didn’t want to mess with that, then the only other thought is to create an IF column that returns a default role if it’s empty, otherwise return whatever is in the column. There is no mass updating like you can do with SQL.

As for reverting…if you make component changes and don’t like them, and catch it right away, there is an undo option in the builder. Data changes are going to be more permanent. In my case, my main app is still completely sheet based, since it’s a couple of years old. I have a google script that will backup the data once a week by duplicating the sheet and naming it with a timestamp in the file name. So if I ever need to recall data, I can go back to those backups.

As you know, most changes in glide are real time. There’s really no backups of anything for reverting design or data changes. Once you change something, it’s out there. To help prevent any interruption, you can either build new screens that are only visible to you and change the visibility when ready for production, or just work in small pieces without changing too much at one time, or do your work when the app has it’s lowest usage. Lots of ways to handle it. I usually just jump right in and make changes since I have only a handful of users, but I still try to do things in such a way that it doesn’t affect any existing functionality, or it’s something that’s only visible to me.

3 Likes