please explain me next information.
I have app with CoreDataModel1, and now I create CoreDataModel2. And I need to use CoreDataModel2 in my app. I read about migration and ti's work fine. But I don't need the previous data from CoreDataModel1. How I should do this. When I make migration all my previous data copy to CoreDataModel2 but I don't need it.
Normal Core Data migration doesn't need this, because there is no copy. The migration process updates the persistent store file to use the new model, keeping the same file. There's no old file to delete.
If you have implemented a custom migration scheme that does copy the data to a new file, then you're on your own. You remove whatever old file(s) your scheme leaves behind that you don't need any more.
The way I understand your problem, you do not care about the old database file or data. In this case, you might just create a new model with a new persistent store url (i.e. file name) and ignore the old one.
The standard way is to simply select the second model version as the current one, switch on
NSMigratePersistentStoresAutomaticallyOptionand
NSInferMappingModelAutomaticallyOption,
and if need be delete old data upon startup.
Related
I have some general questions about iphone app updates that involves sqlite db.
With the new update does the existing sqlite db get overwritten with a copy of the new one?
If the update doesn't involve any schema changes then the user should be able to reuse the existing database with their saved data, right? (if the existing database doesn't get overwritten from 1 above )
If there are some schema changes, what's the best way to transfer data from the old database into the new one? Can some one please give me guidelines and sample code?
Only files inside the app bundle are replaced. If the database file is in your app's Documents directory, it will not be replaced. (Note that if you change files inside your app bundle, the code signature will no longer be valid, and the app will not launch. So unless you are using a read-only database, it would have to be in the Documents directory.)
Yes.
What's best depends on the data. You're not going to find sample code for such a generic question. First, you need to detect that your app is running with an old DB version. Then you need to upgrade it.
To check versions:
You could use a different file name for the new schema. If Version2.db does not exist but Version1.db does, do an upgrade.
You could embed a schema version in your database. I have a table called metadata with a name and value column. I use that to store some general values, including a dataversion number. I check that number when I open the database, and if it is less than the current version, I do an upgrade.
Instead of creating a table, you could also use sqlite's built-in user_version pragma to check and store a version number.
You could check the table structure directly: look for the existence of a column or table.
To upgrade:
You could upgrade in place by using a series of SQL commands. You could even store a SQL file inside your app bundle as a resource and simply pass it along to sqlite3_exec to do all the work. (Do this inside a transaction, in case there is a problem!)
You could upgrade by copying data from one database file to a new one.
If your upgrade may run a long time (more than one second), you should display an upgrading screen, to explain to the user what is going on.
1) The database file isn't stored as part of the app bundle so no, it won't get automatically overwritten.
2) Yes - all their data will be saved. In fact, the database won't get touched at all by the update.
3) This is the tricky one - read this fantastically interesting document - especially the part on lightweight migration - if your schema changes are small and follow a certain set of rules, they will happen automatically and the user won't notice. however, if ther are major changes to the schema you will have to write your own migration code (that's in that links as well)
I've always managed to get away with running lightweight migrations myself - it's by far easier than doing it yourself.
What I do is that I create a working copy of the database in the Documents directory. The main copy comes with the bundle. When I update the app I then have the option to make a new copy over the working copy, or leave it.
I know I can set a Pre-Populated SQLite file as CoreData persist file. But When I update my app version, and the Pre-Populated Data need be updated, I wonder if there has another way to do that except CRUD the new Pre-Populated data by codes after the new version launch.
You can pick the pre-populated sqlite file as a source file in the persistentStoreCoordinator but keep in mind that if you update de data, the user generated content will be lost...
In one of my project I have also faced a similar problem. My approach was that.
Create 2 configuration in Core Data. One for static data and second for dynamic data.
While configuring your persistantCordinator set two separate SQLite files corresponding CoreData configuration.
There is not extrac coding effort other than setting up two separate DB in persistantCordinator level. Everything else will be managed by CoreData like. Reading, Writing etc.
For static database keep a DATABASE version of your own. When your static data changed increase this database version and in App launch check the existing database version with this new version. If new version is greater copy and replace the existing static database.
With this approach you have the following benefits.
You wont lose your dynamic data.
You need to change the static database only when there is a change in static data.
Hope this helps.
I'm updating an app to a whole new version (remade). Everything is going to change to be faster and less bugy. As other post suggest I cannot create another version of the model since I don't have the app code to the previous version (I started a new project). All I have is the bundle identifier for it to be an update. I will use core data but I want to delete all the old models and old data for the users that are updating, as if they deleted the app and reinstall it. How do I achieve this? or there's no need to delete anything because is a different model? All i want is to prevent app crash on launch. thanks in advance.
If you tried to open the same persistent store file with a model that doesn't allow Core Data to make sense of it then you'd raise an exception. So probably all you need to do is use a different file — remember that you get to specify the on-disk location in addPersistentStoreWithType:configuration:URL:options:error: — for your persistent store and ask NSFileManager to delete the old one.
I don't think there's a penalty for asking to delete a file that already doesn't exist so no need for any particularly complicated logic. You'd just be duplicating what the file manager does internally anyway.
Alternatively, if you prefer to keep the same file, enclose your call to addPersistentStoreWithType:... in an #try/#catch block and in the #catch just delete the existing file and try the addPersistentStoreWithType:... a second time.
Our app got released in app store and now I wanted work on next version. Here I might add property and entity to current model .
I am using core data with Magical record .
I need help on core data migration with magical record .
I am already using [MagicalRecord setupCoreDataStackWithAutoMigratingSqliteStoreNamed:#"xxxxxxx"]; in app delegate .
As per my understand MR will take care of migration if we use above method .
Should I need to do any changes in Model.xcdatamodeld like adding model version (Editor->Add model Version) .
Please help me how can migrate core data.
To build on #casademora answer who obviously knows a lot more about MR than me, here is what got stuff working for me. The key is reading the Apple docs as suggested.
highlight your existing .xcdatamodel and then click Editor > Add model version > name it with an increment from your previous (i.e. if "myapp" use "myapp 2" as suggested in xcode.
make your changes on the newly created .xcdatamodel.
highlight the parent .xcdatamodel and then on the File Inspector on the right of xcode select your new version as the current Model Version.
NOTE: This step is only required if doing more than a Lightweight Migration. Select File > New > File > Core Data > Mapping Model. Choose your original as source, new as target and then save in the same folder as your .xcdatamodel.
make sure you are using setupAutoMigratingCoreDataStack or setupCoreDataStackWithAutoMigratingSqliteStoreNamed of course
test by downloading the app from app store and opening it, then closing and running debug over the top. You should not get any "Removed incompatible model version" messages (i.e. all persistent data should be in place still) or any other errors.
That method simply enables auto migrations to happen when you have multiple versions of a data model in your application bundle. To add a new version of a data model, you'll need to select your data model in Xcode, and in the menu select Editor -> Add Model Version... From there, Xcode will do the proper setup for you. This is also a fairly simple idea, it creates a new data model file, that starts off as the contents of your current data model file. From there, you can change and edit your data model as you see fit. Be aware that only simple changes are "automatic". Adding a new property is valid if it has a default value. Adding a new entity falls into the automatic category as well. I suggest reading more details about Core Data Migrations from Apple's Official Documentation
i have submitted an app on the app store that uses core data.
The problem is that i duplicated my project and then lost the first source code. If i update the app using the "duplicated" source code does it delete all core datas users may have stored? i know that if you change the file file-xcdatamodel without mapping the previous datas you will lose all you had stored, can i assume the duplicated project use the exact same file?
thanks in advance
In that case I think that, if you didn't modify your xcdatamodel, the data stored by user will keep during the upgrade. In order to be sure, you can install your own apo from App Store, save some data, update this app from Xcode with your new version and check if the stored data still are there.
If you've modify your xcdatamodel, you must perform a light or a heavy migration, depending on your canges.