Implementing magicalrecord style handling of store structure change

[jyaunches]

So one of the things I liked about magical record is that it if your store changes.. instead of crashing on app launch (and loading of the persistent store from file system).. it attempts to just delete the existing store and create a new one.

This is useful while your app is in development because currently if you're pushing out builds every day or couple of days to your team of internal test users, you have 3 options for handling database changes.

1. Do a migration for every build
2. Tell them if it crashes, to delete and reinstall

With this implementation.. you can just tell them that they may lose data between installs.

Discussion areas:

1. This currently blindly deletes and recreates the store on any error.. would be interested in narrowing that.. and have some ideas for how to do that, but thought I'd ask for ideas on what other errors can come through this.
2. Might be good to just have this as a feature that can be enabled/disabled. Or available for development only? Interested in thoughts!

[PGLongo]

Thanks for your PR. I want to discuss with @michaelarmstrong before merge it.

I think that deleting the store is not the best solution. I don't like the idea to lost all the data, maybe it would be better to rename the old one.

[michaelarmstrong]

Hey,

Perhaps it's something that can be configurable, so users have a choice. I personally use an in memory store for development but I see how this can be useful too.

 SuperRecord.deleteStoreForIncompatibleModel = true 

or something?

Sent from my iPhone

On 16 Jun 2016, at 09:52, Piergiuseppe Longo notifications@github.com wrote:

Thanks for your PR. I want to discuss with @michaelarmstrong before merge it.

I think that deleting the store is not the best solution. I don't like the idea to lost all the data, maybe it would be better to rename the old one.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[PGLongo]

@jyaunches and @michaelarmstrong do you think that this feature would be useful for development or also in production?

I think that it's too dangerous deleting the data. Imagine this scenario:

• User has version 1.0 of the app but the current is 1.2
• The developer has correctly handled the migration from 1.0 to 1.1 and from 1.1 to 1.2, but there is a bug for user migrating from 1.0 to 1.2

I prefer to have a crash (with a log, like Fabric) and fix it in 1.3 instead of an angry user who has lost is entire data.

If we are discussing only about development we could use a debug flag.

#if SUPER_RECORD_DEBUG
deleteStore()
#else
//CRASH
#endif