I have an app at the App-Store right now that uses Core-Data with persistent store to save the data as SQL-Lite-store-type, locally on the device.
Actually the Model is very simple, I have only one NSManagedObject in it, called "Product".
In the next version I want to edit "Product" properties in the following way: add a new property and remove 5 properties. (Without the app crashing because of the inconsistency...)
Plus, on the first launch of the application after the user upgrade I want to delete the old stored-DB, because it won't be relevant to the application any more.
I read "Core Data Model Versioning and Data Migration Programming Guide", but still not sure what is the best practice in this case. (Should I use "Lightweight Migration"?)
Please help me...
Using the Lightweight Migration is the simplest choice here. If all you are doing is adding properties, lightweight migration lets you avoid dealing with the inconsistency errors.
Related
I already have an app in the app store. I want to do an upgrade. My local data store has changed, with an extra table, and with a few fields added in the existing table. I want to retain the data in the old tables. How would I go about doing that? Could someone point me to tutorials that handle that kind of change?
Assuming you're using SQLite: Use a new database with a different name for your update. On startup, check for the table with the old name, copy the data you want, and delete it when you're done.
CoreData has it's own update data which may or may not work for you. You should look into how to change the data model.
Check out Apple's docs on migrating a core data instance. They make it super easy for 90% of the cases. The basic idea, is you break you xdatamodel into versions, so it has a path for migration
Here's a tutorial that might help you Core Data Migration
When I try to add a new ManagedObject to an existing relationship of an entity using the Core Data generated method "addArticleObject", a fault is fired for the articles relationship. Is it possible to add an object to a relationship without causing a fault to fire for the existing objects in the relationship?
I'm not sure I'm understanding your question exactly, but if you modify your core data model, as long as you go on the simulator and delete your app, then rerun it (so it regenerates everything), then you should be fine. You also might have to delete and recreate your NSManagedObject classes, but that's a quick thing also.
If you've altered the structure of your Core Data model, unless you've done so with a migration you'll need to clear the previous version from the Simulator and any handsets you're testing on. The error which occurs if you don't isn't particularly helpful.
Use the 'Reset contents & settings' option in the Simulator, and delete and reinstall the app on a phone. Simply rerunning the app isn't enough.
It seems that it is not possible to add objects to a many-to-many inverse relationship in Core Data without having both objects in the relationship in memory. I'm sure there must be a good reason for that requirement, which I would like to know. This has however caused me to have to refactor the database and all associated code
I have a published app in the appstore. Recent changes to the app require me to add an extra field in the CoreData db.
If i do this without altering the other fields, will the update be succesful?
If not, how can i add a field to the db without damaging the app for the clients that already had the app?
You need to use Core Data Migration to do this. You should be able to do it with Lightweight Migration, which means it can be done automatically.
This is covered very well in a number of tutorials and examples. Here is a link. Look at the accepted answer to that question.
Here is another one: Can I use “Automatic Lightweight Migration” if my already release v1 didn't have a versioned Core Data model? That should set your mind at ease.
Here is a tutorial that is a little easier to digest.
I have used automatic lightweight migration, and it is painless for the type of change you are describing.
Ok, I am admittedly pretty new to core data, and am still not quite as knowledgeable as I would like to be. I am doing some pretty basic data retrieval from the database using values that I went in and added myself (using the sqlite editor Base).
I got everything working in my simulator, and I thought that life was just dandy but I went in and installed the app on my 2g iPod touch, and when my pickerview went to go get data...there wasn't anything there! I guess it's not terribly surprising, but I was thinking that the app build would just copy the db that I had setup??
What is going on? What do I need to do to make it so that the pre-loaded data is available for any and all downloaders of my app?
Thanks!
The core data persistent store won't get automatically added to your app. You will need to add this file to your project so that it becomes part of the app bundle when you build the app. You can see what will happen in xcode after you've added this file under your target settings.
Additionally apple discourages modification of the SQLite data store directly outside of core data. You may be better off just using SQLite in that case. If you feel you really need core data, you may want to make a default SQLite database that is part of your app. The first time the app is run (or the data is reset) you can then import that data into your user's custom core data persistent store. See this portion of apple's documentation on how to import an existing SQLite database into core data. This allows you to have default data but gives you the flexibility of being able to reset the database easily.
I just wonder what this third panel for versioning configuration is, in the Xcode data modeler on the top right, third tab. Want to see some examples for what this is good for and wether or not I should already provide versioning information right from the beginning.
Any cool link and hint is appreciated.
The first thing I'd read would be Apple's Core Data Model Versioning and Data Migration Programming Guide.
You don't need to provide versioning information from your first build of an application. However, once your application has seen its first release and people are starting to use it, you will want to add versions of your data model for each time you change that model. Simple changes to the data model can be automatically migrated at startup of your application using the lightweight migration feature introduced with iPhone OS 3.0 and Snow Leopard. More complex data model changes may require setting up manual migration.