Hello, I have the need for a "staging" environment for interfaces. By that, I mean it would be valuable for me if I could "disconnect" the interface from the underlying data when needed. The idea is to avoid having users see intermediate states of the database while it is being updated. While the read-only interface is "disconnected", users can only see the data just before the disconnection and would see the new state once the interface owner re-engage the connection.
Staging for Interfaces
+12
+3Hey, I would maybe duplicate the Interface and keep it unpublished? Or simply make the changes in the Interface you have but do not hit Publish?
+12Hi, that would work to stage the interface look & feel but what I am interested in is staging the data itself. In other words, I would be interested in having the interface show a snapshot of the data until I am done updating the data....
+12I figured out a way which consist in introducing an overarching table of versions and use this version as a prefix of the actual records. It is quite involved but remains manageable.
I figured out a way which consist in introducing an overarching table of versions and use this version as a prefix of the actual records. It is quite involved but remains manageable.
Curious how you solved this. . . I'm facing the same issue. IN my case I'm also changing the interface and working on scripts, potentially renaming fields so this solution might not work? Sounds like this is just about keeping a record of the values in the records not overall changes to the database structure.
+12Curious how you solved this. . . I'm facing the same issue. IN my case I'm also changing the interface and working on scripts, potentially renaming fields so this solution might not work? Sounds like this is just about keeping a record of the values in the records not overall changes to the database structure.
I used different version prefixes for my items and filter the interface on a specific version. Lots of duplication involved but also helpful for traceability in my specific case. I think I saw Airtable now has a staging future. not sure...
That would be great. The way we got around this limitation is by creating a guid field for our tables, The id field is copied to the guid field. I then made sure that any references refer to the guid field not the id field so that a reference to a record will be persistant even when the table is duplicated and all the record id values change.
I guess a simple solution on airtables part would be to make the id field persistent instead of having the recordID be randomly generated when a table is copied. Ideally it would just be the base ID that changes so everything else in your app stays the same, but typically tables are called out by a name not id since the developer has control over naming.
Login to the community
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.