Please tell me everything practical about stable memory

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:

  1. 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?

  2. 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.

1 Like