Looks cool. What would be the prototypical use cases for something like this?
I'd imagine something like this would already have been possible with a proxy (i.e. hot swap upstream without closing client connections).
Also, any idea how this handles clients that execute scripts via EVALSHA? If a client already loaded the script, wouldn't this break that expectation or does the client contract not allow caching that?
Hello koolba, I did not expect this commit to reach HN, but here we are... so: there are different use cases but distribution of read-only data to far places with an easy upgrade path for the data is one that comes to mind. Since this pattern is requested very often there are for sure other applications. About Lua, the scripts are atomic from the POV of Redis, so the swap happens before or after the script is executed: they should work as expected AFAIK, but thanks for hinting about that.
In a previous job, we'd receive weekly updates of data from a vendor that would need to be imported into the database. There were a few occasions where the update file had errors which would break the application where this data was used. Features like this mean that one can very quickly roll back to previous known good data, and also troubleshoot a problem by comparing results to what they were last week/month/etc.
I'd imagine something like this would already have been possible with a proxy (i.e. hot swap upstream without closing client connections).
Also, any idea how this handles clients that execute scripts via EVALSHA? If a client already loaded the script, wouldn't this break that expectation or does the client contract not allow caching that?