5 ms·
If a git commit hash was directly tied to a data hash at that state (IPFS), that would be trivial.
by chaxor 3y ago
If a git commit hash was directly tied to a data hash at that state (IPFS), that would be trivial.
- tbrownaw 3y agoOr have the SAN make a snapshot of your db before the deploy, no fancy solution-looking-for-a-problem tech needed. Completely reverting all the state to some point in the past is easy and have been a solved problem for quite a while. The actual problem is undoing states changes related to the code change, while not losing state changes related to normal system activity. If I add some new fields to how my web forum records posts, and then find out that it's eating every tenth post and need to revert, it'd be good to not lose and posts made in the meantime.
- chaxor 3y agoGood point, this system is much more useful for scientists and ML researchers, etc. wherein the code may generate datasets over several weeks or months of compute time, but produce some output that should be directly tied to the code. You're right though. Systems in the social media space dealing with users appending to a database typically don't have this requirement to be easily reproducible, so the local snapshots are the right choice.
- baq 3y agoAnd useless. Unless customers don’t care about their data.
- chaxor 3y agoI don't understand your statement. If a git clone of a specific commit also pulls the data that is generated from that commit hash via IPFS simultaneously, then you can always have the data at whatever state you choose. How might this have a negative effect on conserving the data? Do you mean that there are additional structures required to manage keys if the data is encrypted?
- rjmunro 3y agoOnly if there were no changes to the data.