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.
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.
I am working on an iphone application that uses sqlite to store application and user data.
This is the first version of the application and I wonder what I need to do to prepare for the future versions of the app.
Is this enough?
1. Make sure app version is correct in the XCode Project settings
2. Add a version number in sqlite file so that it can be read later
Lets simulate the next update!
1. New version of the app is downloaded to the device
2. The app reads the version number stored earlier in a sqlite table/field
3. App knows that application data has changed so it needs to update the sqlite and also
it wants to retain the user data (in app favorites & Notes).
4. Schema has not changed so it starts to insert the new application data into some tables.
5. It does not touch the user data tables
6. It updates the version number of the sqlite db.
Have I missed something that will come back and bite me when it is time for update?
So, when you develop an application that uses Core Data you start defining a Core Data Model. Each model will have its own version. You start creating the first and unique version of your model. You can find all the required, detailed, info at the official Apple Core Data Model Versioning and Data Migration Programming Guide
You should not handle database versioning through custom fields set in the database itself, use model versions instead via your Xcode project.
When updating the application, if you do not change the model version you do not have to worry about anything, since the database hasn't been touched. Every new update that do not change the model will require no effort from you.
If you need to update your model for the next update you have to do this:
Create a new model version
Set the new model version as the active version
Modify the model according to your needs
Here comes the interesting part. Your application will handle the migration between the models in two different ways: the simple way and the hard way.
Automatic lightweight migration
Following Apple's official documentation about Core Data Model Versioning and Data Migration, if your model has been slightly changed you can ask the application to perform an automatic lightweight migration. This step will update the existing database to the new version if these requirements are met:
Simple addition of a new attribute
A non-optional attribute becoming optional
An optional attribute becoming non-optional, and defining a default value
The lightweight migration process will handle the appropriate required step to migrate from one model version to another, if possible
Mapping model migration
If you can't perform an automatic lightweight migration you will have to manually define the step to update
the model versions to the new one, using Mapping Model Objects. These objects will define what the application has to do to migrate from model version x to model version y.
I am releasing a Core Data based app and wondered what I need to consider if, in an update later down the line, I need to change the model.
How do I move existing user data on the device from the old data model into a new updated model?
Thanks
Generally, you'll have to consider nothing now but as soon as you change your data model, you'll have to employ Core Data's model migration tools. Read the Core Data Model Versioning and Data Migration Programming Guide.
We're beginning development of an in-house app in the iPhone Enterprise developer program. Since it's close to OS 3.0, we're reconsidering our original design of using SQLite and using Core Data instead. Here's some more info:
There is a legacy desktop application that this is replacing. We will reuse the existing back end.
We currently have a SQLite database generated as a proof of concept. This is basically a cut down version of the existing back end database.
We will be loading data from a remote site and storing it locally, where it will persist and need to be . We only update it if it has changed, which will be every month or two. We will most likely use XML or JSON to transfer the data.
There are two developers on this project and we both have strong SQL skills but neither one has used Core Data.
My questions are: what is the benefit of Core Data over SQLite, what would the benefit be in this specific instance and do the benefits justify learning a new framework instead of using existing strong SQL skills?
EDIT:
I just noticed this question: Core Data vs SQLite 3. I guess my questions therefore are:
If I have to check if a specific item either exists or has an update, which is easy using SQL, does Core Data still make sense? Can I load the first object in a graph and check the version number without loading the whole graph?
If we already know SQL, does the advantages of Core Data for this one project justify us learning it?
As you've read Core Data vs SQLite 3, you know that Core Data and the persistence mechanism (SQLite in this case) are largely orthogonal. Core Data is really about managing an object graph and it's main use case is for the model component of an MVC architecture. If your application fits nicely into this architecture, it's probably worth using Core Data as it will save you a lot of code in the model component. If you already have a working model component (e.g. from the existing desktop app), then Core Data won't buy you much. A hybrid approach is possible-- you can do your own persistence/querying and build a Core Data in memory store which you populate with the result of a query and use this in-memory store via Core Data as the model component for your app. This isn't common, but I've done it and there are no major roadblocks.
To answer your specific questions:
You can assign a version number to the entire persistent store and retrieve that information via +[NSPersistentStore metadataForPersistentStoreWithURL:error:], without even opening the store. An equivalent +setMetadata:forPersistentStoreWithURL:error also exists, of course. If you want to store the version info in an entity instance instead of in the persistent store metadata, you can load only a single object. With an SQLite persistent store, Core Data does a very good job of fetching only what you need.
The NSPredicate API, is very easy to learn and it seems to do a decent job of compilation to SQL. At least for databases of the size you could fit on an iPhone it's certainly been adequate (performance wise) in my experience. I think the SQL vs. Core Data question is slightly misguided, however. Once you get the result of a query what are you going to do with it? If you roll your own, you'll have to instantiate objects, handle faulting/uniqueing (if you don't want to load the entire result of a query into memory immediately) and all of the other object graph management facilities already provided by Core Data.
It sounds like you already have the project designed using SQLite, and you have experience in that area.
So the bottom line is, does it make sense to port this project, will Core Data give me anything that I didn't already have in my original design?
Assuming that the original design was done properly, based on the requirements ON THIS PROJECT, it's probably not worth it.
But that's not the end of the discussion. There are other things to think about: Will my next project have such light database requirements? Do I need to ship soon, due to timeline or budget constraints? Assuming I'm going to have to learn Core Data sooner or later, doesn't it make sense to do it now? Am I possibly interested in porting my code over to the Mac?
The answers to these questions may lead you to the decision that yes, it is indeed worth it to go back to the drawing board so to speak, and learn what Core Data is all about.
To get to your final question: What are the advantages? Well, Core Data is a higher level abstraction of your database, it is also data store agnostic (so if a future version of the iPhone were to ditch SQLite for an embedded version of MySQL... unlikely, but it's an example) then Core Data would require VERY few changes to the code to make it work with the new data store. Core Data will provide a great deal of quick portability to the Mac platform. Core Data will handle versioning of your data model, whereas unless you have a framework or a workflow to manage it, direct access to SQLite won't.
I'm sure other answerers can come up with other advantages, and maybe some good reasons why NOT to mess with Core Data. Incidentally, in a similar situation, my decision was to port to the higher level, newer framework. But in my case, it was for a side project, and ship date and budget were non-factors.
Not to detract from this forum, but you might find more respondents with contextually relevant experience at the Apple iPhone DevForum.
Speaking from a purely project management perspective, it sounds like you know how to build what you want to build using SQLite, and so it would make more sense to me for you to start along that route.
That being said, CoreData builds on top of SQLite and if you are trying to leverage other parts of the system in conjunction with your data, e.g. using KVC/KVO or bindings, then you may quickly find that this functionality is worth the learning curve.
= Mike