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.
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
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.
My iPhone app's core data model is changing and I have a custom mapping model and an NSEntityMigrationPolicy for one of my objects. However, I am worried that some of my users will have thousands of objects in their core data base, are there any best practices for either making the migration as efficient as possible, or conveying to the user what's going on when they load the new update which will try to migrate their data?
You need to warn the user that the app needs to update the data store and you should probably provide a "working" dialog so it doesn't look like the app has hung.
However, the migration is very efficient because it's really just changing the mapping on the store. It doesn't have to actual instantiate all the existing managed objects, it just changes the field names in the store. That can get complex itself in rare cases but most of the time it's barely noticeable.
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.
I'm working on an application that has a read-only database shipped with it.
The user will run the application and be able to select a series of "favourites" from the database which will appear in there "favourites" tab bar section. I.e. storing the primary keys.
With each update to the application the read only data will potentially contain more entries or have things like spelling mistakes fixed etc.
I'm using Core Data but I'm unsure whether to use it for storing the users "favourites" as-well. As - to my way of thinking - this might cause headaches for migration. Is this the case?
Should I consider storing the "favourites" in a plist perhaps and perform some sort of query to retrieve the records? Any recommendations?
Also what internal pieces of an iphone application are kept (or can be kept) during an update?
Phew I think that's it.
Thanks for any answers you might have.
Cheers,
Matt
I'm using Core Data but I'm unsure
whether to use it for storing the
users "favourites" as-well. As - to my
way of thinking - this might cause
headaches for migration. Is this the
case?
If you're going to port the app to another platform, then Core Data is not the way to go. And since we are talking about a static database, I'd keep it simple - read it once, do what you need with it and close it and forget about it. Not like a real database where you're doing multiple GETs and some amount of additions, modifications and deletions.
Should I consider storing the
"favourites" in a plist perhaps and
perform some sort of query to retrieve
the records? Any recommendations?
Your database could be a plist too. After the user selects their favourites, you can easily store them in yet another plist. This one goes in the Documents or Prefs folder.
When you release a new app, you should probably compare the favourites with the new entries to correct any typos or other changes, if applicable.
Also what internal pieces of an iphone
application are kept (or can be kept)
during an update?
I believe that your app is replaced but your Documents and Preferences folders are kept intact.