Should you clear storage when changing your schema? about mst-persist HOT 2 CLOSED

Hey @lon9man sorry for not responding to this. My GitHub status at the time mentioned I was taking a break from OSS due to toxicity and abuse. Coming back now per my current status.

Getting to the question at hand, this is a schema change / migration question. #23 actually talks about multiple ways to do migrations -- very similar to how DBs handle it. I've reworded the title to mention this.

One way could indeed be to clear all storage as you suggest and just start from scratch. If the offline data can be easily retrieved, resetting in that fashion may be a good option.

Another way would be to run a migration when a schema change is detected. Effectively, this would be the same as back-end DB schema migration, but done client-side on pure JSON (or JS objects if #23 is implemented). Each migration would likely have to be hand-coded, there isn't necessarily a simple way to automatically figure out what to do when a schema changes (same as with a DB).
Backward-compatible migrations are a whole topic in DBs with multiple ways of achieving them, so I can't really describe that with the depth it requires in an issue. Some examples include adding defaults, splitting into multiple migrations, etc.

I would recommend thinking of your persisted information as a secondary DB or cache; you can model interactions with persisted data fairly similarly to that of a back-end DB or cache.

from mst-persist.

any ideas?

from mst-persist.