clear storage on upgrade store

[lon9man]

Main Question what do you think about clear storage, when its structure was upgraded (extended, updated, ...)?

Example

1. development iteration 1: create basic model

const User = types
.model('User', {
    id: types.number,
    name: types.string,
  })
  
const UserStore = User.create({
  id: 1,
  name: 'John Doe',
})

persist('@UserStore', UserStore, {
  storage: AsyncStorage,
  jsonify: true,
})

2. development iteration 2: model extended with email-property, BUT in AsyncStorage persisted OLD model already and restoration of it will fail due to difference in the structure.

const User = types
.model('User', {
    id: types.number,
    name: types.string,
    email: types.string,                 # added property
  })
...

THOUGHTS: on the first run of application (after store's structure was upgraded) we should detect such changes and clear storage. on the next runs - we should work with persist as usual. it looks like upgrade of the databases saying in Android (migrations and etc)

[lon9man]

any ideas?

[agilgur5]

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.