I understand and appreciate the private tables pointer. However I want a solution that is more secure and truly keeps the data pointers separate so that there is zero connection from customer A of an app to the data of customer B, both using the same app “code”. I view that as a workaround to achieve the same thing in a less secure way.
@Marc_Dillon regardless of the approach, I still have to fixup the table structures for the other customer, whether the app assists me with not updating the pointers or whether I play the manual games to do the equivalent, my customer B app still won’t load unless I alsoi update data instance B’s structure to match the new app “code”. So I can see this as a valuable feature and if the resulting upgrade of an app with this feature enabled (to not copy the data ptrs) fails to load, that is ok, and is expected, I then need to update that instance’s data sheets.
The data and the app are not truly decoupled and cannot be deployed to production separately in a proper manner.
Conceptually the google sheets themselves are independent of the appsheet data/code. The interface to get them to work together is the column structure implicit “api” that is implemented in the appsheet development UI with errors for mismatches. This particular issue I am pointing out is that this “data” vs. “code” interface is difficult to develop in for some development patterns like the one I want to use.
I want to release my app additionally as “open source”. Overall I have these instances:
- customer A production
- customer B production
- open source
Separately, I plan to write up my challenges with that and solicit feedback on the best mechanism, as well as examples of how other people have done it (if it has been done). The requirements I would like for the “open source instance” are:
- there is zero connection to any customer data
- the open source and production instances can be upgraded from my development app smoothly