5 ms·
If I understand the persistence stuff correctly, programs don't do explicit I/O but instead just run forever and thus use normal variables and data structures t
by marvy 6y ago
If I understand the persistence stuff correctly, programs don't do explicit I/O but instead just run forever and thus use normal variables and data structures to store state.
This sounds very convenient until one fine day you decide add a new feature, so you need to change your code, but the new code has different variables and there may not be any sensible way to "port" the data.
- coldtea 6y agoNot sure what the problem is supposed to be. Is the idea here that the programs don't do I/O (e.g. to disk/db/etc) ever? Because that's not probably what it happens...
- arethuza 6y agoSounds more like you don't have to worry about mapping your variables to and from an underlying persistent store - it happens automagically. It's an idea that has been tried on and off for decades and is obviously very appealing but tends to have lots of interesting problems when it has been used for a while - often when you want to access your data outside the context of your application.
- deleted 6y ago[deleted]
- jpalomaki 6y ago” Motoko provides numerous features to help you leverage this environment, including language features that allow your heap to self-migrate when you upgrade the software of a canister.” https://sdk.dfinity.org/docs/language-guide/motoko.html https://sdk.dfinity.org/docs/language-guide/motoko.html So in this sense it could be a bit like creating migrations to your database. Maybe on ”cloud scale” you just would like to migrate the data when it is used. Edit: Few more details in this document: https://sdk.dfinity.org/docs/language-guide/actors-async.html https://sdk.dfinity.org/docs/language-guide/actors-async.htm...
- marvy 6y agoOkay, so the magic ingredient is that variables that are marked "stable" are treated specially. Nice!