Hi @ielashi thank you for your answer. Sorry, I should have been more specific probably.
I have a reasonable understanding of the pre and post-upgrade hook. I think I’ll use the stable hash map to get around that. I’m thinking about how exactly I should be doing migrations. I have a number of questions on these topics:
-
I’d like to understand how much stable memory (and wasm) my canister is even using. How can I do that?
Yesterday I played with the Prim.rts_heap_size, Prim.rts_memory_size, and with the ExperimentalStableMemory library and I ran “dfx canister status”. But I’m still not quite sure which function is telling me what. What does “rts” mean? Do I understand correctly that the functions in the ExperimentalStableMemory library are just calling the ones in Prim? But not all functions are exposed in the ExperimentalStableMemory library? -
Concerning migrations, this pattern does not seem too bad but I still think I could screw this up easily. Business logic, data, schema, and migration logic all being on the same thing feels tricky. If I use that pattern I think I’d really want to be able to have my state backed up before I do anything. Is there progress on the ability to copy/clone canisters? Or are there other simple ways to dump all my state to somewhere else (can be off-chain)? If I just use a getter function is there an example of how I should chunk the calls to get around the message size limit? And in what format do people store the backed-up state off-chain?
Thanks again for the help.