Migrate persisted user ui settings to latest schema

[ntziolis]

We use akita + persitance to store user ui settings in our apps. As an apps progress the schema of this data changes. This is akin to database migrations on the server side.

I know that under the covers akita uses the same mechanism t store the data as redux. Looking at migrations +n redux I found the following, but due to lack of further info + redux knowledge I'm not sure if this is a viable path:
https://github.com/rt2zz/redux-persist/blob/master/docs/migrations.md

What is the best way to achieve this? Optimally in a non redux manner.

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[x] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

[NetanelBasal]

Akita doesn't support migrations.

[ntziolis]

Understood, any pointers where to look to custom built this? Happy to build a lib for akita as we def need this.

[NetanelBasal]

Read the persist-state source code.

[xbaun]

Assign to each store state a version number, then intercept the initial state imports from storage by passing a custom preStoreUpdate callback: If the version number doesn't match the expected, then trigger a migration.

• https://github.com/datorama/akita/blob/3f4e5ae87c9a9bca46b5b41f8db6cd57390e77bb/libs/akita/src/lib/persistState.ts#L70

[ntziolis]

Totally understand that most people don't make an effort to look into the source, I'm not one of those guys. ;)

But I see now that the question was unclear:
Do you have suggestions of any existing js migration lib that are worth looking at in your opinion to base this on instead of writing this from scratch?
Only thing I found so far are a lot of papers but any migration lib I could find is node and not browser based besides the redux one above.

Any suggestions are highly appreciated.

@xbaun Thank you for the pointer. For simple scenarios (data resides in same store) this will work just fine and is a great start

Here are some scenarios we have already encountered and would like to cover with migrations:

• field renames (this would work with preStoreUpdate)
• store was renamed (refactoring)
• data from one store is split into multiple
• id column of store changes
• new store is added that references ids of data in other store

[NetanelBasal]

I'm not familiar with any library. But I know that indexeddb has a nice built-in migration API.

[ntziolis]

@NetanelBasal Got it thx. Thats def an avenue we are looking at. The migrations for Indexeddb look very much the same as our backend migrations which could be a plus even if they are slightly verbose at first sight.

[j2L4e]

Nevermind, my suggestion only partially covered your use-case (same-store).