0
votes

At the moment i have one Persistent Store Coordinator which is backed up by a sql database. I have a lot of Entities in it. When i change the Model i try to use leightweight migration. If it failes i just delete everything and set it up again. For now this works fine. Now lets say i have to save some kinde of Bookmarks. Since you can have multiple bookmarks i think it is the best to save this also with core data. However in this case i need a real migration strategy so the user does not lose its bookmarks.

I'm thinking about creating a seperate persistent store coordinator which only contains the bookmark entity. With this one i could then do mirgations if necessary and the other perstitent store can be used as it is without migration.

Is this possible and recommended ? Or are there any pitfalls i have to watch out for. I hope i could explain my situation correctly. I was also thinking about saving the bookmarks with NSCoding but i'm not really sure which would be better in this case.

Any help is appreciated.

1
Do you have a separation between static content provided as part of the app, and user content which they can modify themselves? - jrturton
What do you mean by that? I'm making a server request when my app starts to get all the data for the first persistent store. So if the data would be gone it is not that bad because i will get the stuff anyway. - kukudas

1 Answers

1
votes

It is entirely possible. It's certainly a good idea to separate the static data that is just downloaded from the server (because it shouldn't be backed up) and the user created data (that should be).

Your main pitfalls are around ensuring that you keep the stores / contexts separate and that your code properly names things so it's obvious what you're working with.

If you have only a few bookmarks, they are small and they are usually all loaded at the same time then NSCoding is an ok option. If you have many, they are big or infrequently loaded then it isn't a great option.