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.
Related
I have very little knowledge about app development, but I am updating an existing SQLite database (simple text changes to the html that is stored within the database). Everything works fine, but when I submitted the app to Apple the changes weren't showing when people upgrade (if you download it for the first time - straight from the App Store - it is fine, so the database must be saved to the cache).
Does anyone know how I can overwrite the existing database? People have said to change the file name of the database, but will this make the app run slower (will two databases be stalled in the cache). Also peoples data are stalled on the database (bookmarks etc.) so somehow that info still needs to be retained if possible.
Any help would be appreciated.
i also would recommend you to rename the database. thats the easiest and fastest way. rename your model and set it to the standard.
i am using this solution, too. my app is not running slower then before. just test it.
please also see this two links for adding new models to your project:
create new model version(apple)
How to Add Core Data to an existing Utility Application
I think that change should happened only in the build u r tested and not in you have uploaded on appstore.
So better way u upload it again... With all testing done.
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
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 releasing an update to my app and I Indexed a few fields in my model to speed up searching and lookups.
Is this going to break my update requiring a re-install? Or will it be a smooth upgrade and those properties will just get indexed the next time the app is run?
I did not change the model in any other way.
Will break. You changed the model after all.
Just change it and let it run in the simulator. it should throw you an exeption since they differ. You could use versioning, but that is a pain for a small change.
Any time you change the model in any way at all, you need to use versioning to continue using existing data stores (like the ones that users already have in their copies of the app). For the changes you describe this should be quite simple-- you can use automatic lightweight migration and the updating should be automatic and quick.
I am planning to create an iphone app which uses CoreData. There might be enhancements added later as new versions of the app.
My question is;
When using CoreData, what are the factors to keep in mind to ensure if the user upgrades the version, his previous data remains intact ? Like I heard we should keep the.sqlite file name same. What are other factors to keep in mind while releasing Core Data apps?
Thank you.
Data migration concepts are important to understand if you're going to maintain it over time, since you're likely to want to change at least some things eventually.
The ideal is Lightweight Migration, where minor conversion from your old data model to your new one is automatic. As noted in the document, it can take care of itself if your changes are:
Simple addition of a new attribute
A non-optional attribute becoming optional
An optional attribute becoming non-optional, and defining a default value
Renaming an entity or an attribute is also easy and nearly automatic.
Everything beyond that -- new or removed entities, new or removed or changed relationships -- is hairier. It's not incredibly difficult, but it's definitely more work, with more room for failure.
As such, a little speculation about likely potential changes may make it easier and more efficient to provide a little wiggle room in advance. Obviously if you do too much, especially with theoretical-but-currently-unused relationships, you're likely slowing down the current system and potentially for no reason.
Worth consideration.
One thing we have done is to manage two separate core data databases.
First, a "read-only" core data database that gets supplied with app updates (assuming you want to be sending data with the app, if not then don't bother with this part).
Second, a local core data database (data store) that's stored on the phone that is initially populated with the data from the first, and then added to by the user or with updates from a server that you control. This second core data store can stay persistent between updates.
For later modification and updates you have two options. You can add additional features in a new core data store as long as you don't need to get at the new data at the same time as the old data. The other option is to use apple's core data migration stuff which you can read more about here.
Here are also some additional resources for gearing up with core data, there are plenty of more specific core data examples on SO.
Finally, if you plan on significantly adding/modifying your core data store I'd suggest looking into SQLite. That's easier to change with updates (in my experience) than migrating an existing core data store to a new schema, especially if the schema changes often.