Just started looking at Retool and trying to understand more around the rollback process. I see within an app there is a way to rollback, but an app will have at least 1 data source. How do you manage datasource rollbacks? If I see right the only way to manage would be to have a resource naming conversion that's tied to an app version. New datasource(s) would be created with each app version and the previous resource(s) would not be deleted.
Or perhaps there is another process that's more integrated
Hi @rwu! Welcome to the community. We're glad to hear that you're considering Retool! I primarily just want to say hi and reiterate the info shared by @khill-fbmc above.
Before I do that, though, are you wanting to rollback the resource configuration or the backing data itself? It's important to note that Retool handles data connections and queries but is not a true DBMS in the sense that it can't be used to create backups, for example.
Even then, resource connectors are configured separately from applications and do not have a similar versioning system, outside of full source control integration at the Enterprise level. It is worth noting that a single resource can have multiple environment configurations, though.
If you do want to implement a crude versioning system for resource configurations, your idea to create duplicate resources with a consistent naming scheme is probably the best option. The fact that resources can be organized in folders would prevent this solution from getting too out of hand, but I don't expect resources to be updated too often, anyway.
I hope that helps! Let me know if you have any additional questions as you explore everything that Retool has to offer.
We're glad to hear that you're considering Retool! I primarily just want to say hi and reiterate the info shared by 