5 ms·
I see your point. But so far we didn't hear many complaints about this feature from the users. The main problem is in forgetting to version code that changed. B
by mfateev 6y ago
I see your point. But so far we didn't hear many complaints about this feature from the users. The main problem is in forgetting to version code that changed. But the system has protections against such cases.
It doesn't end up in spaghetti code as old branches are proactively removed after they are not needed anymore. Temporal provides APIs that allow to count number of workflows using each version.
I don't think it is a leaky abstraction as it is indeed a part of the business logic of deciding how old version of the state should become a new one. I don't think there is a generic solution that allows implicitly migrate old state to a new state on any long running computation.
- jacques_chester 6y agoYou might find the concept of Edit Lenses to be useful. A good writeup is: https://www.inkandswitch.com/cambria.html https://www.inkandswitch.com/cambria.html
- mfateev 6y agoI wish it were that simple :). A workflow is not just externally stored data with a well-defined schema. It is the computation's whole state, including threads blocked on API calls and local variables on the stack. So it is not possible to define translations between different versions the way Edit Lenses do.
- jacques_chester 6y agoSo a process checkpoint? They make me anxious.
- mfateev 6y agoWhy not assuming that you can roll it back to any previous state any time later? Temporal supports such rollbacks.