How to do data migrations when making changes to models?

[dansimau]

Hi folks,

I've been reading through the documentation and something I haven't seen is how to go about versioning of data models.

E.g. scenario is I want to make a backwards-incompatible change to my models. Since these can be reconstructed from a remote server, I am thinking a simple invalidation solution might be something along the lines of:

• Store a version number on each model
• Increment the version number when making a backwards-incompatible change
• Hook into loading on startup to invalidate all objects older than the current version

(This assumes state can be reloaded from somewhere else.)

How are people typically doing this?

Thanks,
Daniel

[coolsoftwaretyler]

Hey @dansimau - sorry it took so long to get to this. I've got one approach for you to consider, but I'm also curious how you ended up solving that.

On my team, we make breaking changes somewhat frequently, and we also use AsyncStorage in React Native to persist and re-hydrate old stores, so we run into this exact requirement.

Your approach would certainly work, but you can skip a few steps by using the typecheck function on a snapshot or node instance. Then you don't have to go through the process of establishing and maintaining some kind of version checking.

Tangentially, you might consider running some of this type checking alongside the lifecycle hooks for nodes, depending on how you're storing/hydrating old values.

I'd love to know:

1. If that's helpful
2. I'd be curious to know where you landed for your usecase.

[dansimau]

Thanks @coolsoftwaretyler this is very interesting, thanks for the reply. Sounds like a very good solution for mobx-state-tree.

I haven't implemented anything yet but I think I am going to go with the versioned approach. One reason is that I intend to generate models automatically from a schema so they are consistent between server/client and I like the fact that the version will be explicit. This can be useful for debugging, or syncing between server/client and leaves the door open for migrations, if we need that in the future.

(Side note: I ended up going with vanilla MobX for now.)