Stable Version and Data Partitioning

Looking to understand a behavior for optimal development. I currently haven’t had any issues, but I want to make sure I’m not barking up the wrong tree, and doing something that will get “corrected” later. Maybe this could get moved to tips and tricks…

In my user table, I assign a value DEV/PRO, whether their account is a development account, or a production user. (this doesn’t tie into anything except data partitions.) So, developers will see the development tables, and regular users will see the production/stable sources. (With this you could actually have each user up on different tables, currently we’re just talking about development and stable tables…)

Rolling in with two data partitions, lets talk about an asset management app.
I would like to maintain a a production/stable data source table for ASSET_STABLE
I would like to then also have a table just for development, ASSET_DEV
(You might be able to get even crazier, and use SQL views tied to the root table, with a view for DEV, and a view for STABLE)

We’re utilizing AWS Cognito for user permissions, and according to @praveen default behavior is that they always see the stable version if one is assigned. We have added our appsheet developer accounts to the appsheet whitelist tagged show most recent version. We think this should all just work fine, even IF the developer email is in AWS Cognito…?

So, current state, in the asset app asset table, we have data partitions set, based on user dev/pro… Both tables currently have exactly the same column structure. AND Stable version is set, and is also the most recent version.

Here comes the rub thanks for staying with me.
If the developer adds a column to ASSET_DEV and regenerates, while logged in, appsheet will look at the development table to catch the new structure. And the developer can continue developing away, seeing what he needs to see. All other STABLE users should be on the stable app which has the old column definition, AND they should be pointed to the data source that matches, so they shouldn’t have any problems syncing changes… Then the developer would send an update email, “hey we’re going to make updates at midnight, if you have problems syncing changes you’ll need to trash them…” Double in and update the STABLE sources with new column structure, then push the app to the new stable version…

Effectively you’ve paired the stable version with a stable source…
And the DEV tables with the most recent version.

(I am also doing this with copies of the app and utilizing the app upgrade feature, becuase then I can use the “Create a new major app version” I wish I could do this with the stable version but appsheet doesn’t expect that we should be making column structure changes in a live production app.)

Open for ideas, and any thoughts, concerns…

1 5 277
5 REPLIES 5

I have an integration like this, and yes: the accounts marked to see the “Newest version” v “Stable version” does indeed work.


I think the app would recognize that one of the other tables (even though it doesn’t really have anything to do with them) has the wrong set of columns.
This might squeek by though…
__

Yes, it’s interesting… when you REGEN it grabs whichever data partition the signed in account is using… So, other than that I’m not sure either… hence my post…

You make a good point… you might be onto something here.

I went back and forth with @tony for some time before I was able to piece all of this together.

Interested in layering in the Rollout options.
If I have a stable version set, and I make changes to the app… If all the users are only listed in Cognito, and not in the Appsheet Whitelist… If I change the rollout to 50, will half of my Cognito users see the latest version of the app? (The other half being on the stable version?)

Top Labels in this Space