1

I have an existing iOS app that uses core data for app data and user data. My problem is that updating app data is a nightmare (my first app, so I didn't do it ideally the first time). I would like to split the app data and user data into 2 separate sqlite dbs (or stores, correct me if my terminology is wrong).

Any tips would be appreciated.

scott4arrows
  • 80
  • 8

2 Answers2

1

Having two sqlite files is a good idea. The pain is splitting them now.

  1. Create a new store that only exists in your app bundle. Make sure the data is unchanged from when you first released the app.

  2. You are going to need to walk the "user" store and find all of the data that is identical to what exists in the "reference" store and delete it. If the user has changed that data then I would leave it and let the user sort out duplicates.

  3. Once that is complete your app can resume normal function and load up both stores. I would set a flag somewhere so that you know this has been done and you don't run the check on every launch. The "user" store's metadata is a good place.

Note, this will need to be done before the user can "use" your app. This probably means changing your launch routines so that if a migration and filter is needed you tell the user what is going on.

Marcus S. Zarra
  • 46,571
  • 9
  • 101
  • 182
  • Thanks Marcus. Follow up question: My app data is a list of awards and requirements. The app allows the user to 'check off' to complete requirements. The user data will be date of completion, but what is best way to reference which requirement in the app store. Adding a unique id for each requirement and storing that with completion date in user store? Or is there something more ideal for cross store references? – scott4arrows Dec 18 '11 at 15:46
  • Marcus, I found what I needed from another SO answer of yours: http://stackoverflow.com/questions/8209932/cross-store-weak-relationship-with-fetched-properties – scott4arrows Dec 18 '11 at 16:33
0

I don't think having multiple persistent stores is the right solution. You can simply have separate entities within a single persistent store. Core Data will handle it properly.

A Salcedo
  • 6,378
  • 8
  • 31
  • 42
  • My app data is a preloaded sqlite db. This provides all of the input data with which the user interacts. The user data is based on this interaction. The problem is that I don't control the app data (other than loading it into the db) and it can change. When it changes, it usually takes more than a simple migration to load the updates. My thought was that using the preloaded db (currently contains 3 entities) as just the app data, and to create a user store to handle/track all user interactions. If the app data changes, I create a new db and swap it with an app update. – scott4arrows Nov 23 '11 at 05:40
  • Having two persistent stores when you are on iOS **is** a good idea. With iCloud backups, etc. it is now more important than ever to watch very closely how much data is stored in the ~/Documents directory. Store too much and the app runs the risk of being rejected. – Marcus S. Zarra Nov 23 '11 at 17:25