I am doing a coredata database migration using lightweight migration in xcode4.5, I kept on getting "Can't find mapping model for migration" when I set "NSInferMappingModelAutomaticallyOption" to "NO". If I set "NSInferMappingModelAutomaticallyOption" to "YES", lightweight migration passes without problem.
Here is the steps I followed:
add a new model version .xcdatamodelId
make changes on the entities (including adding a new entity)
select the newer versioned datamodel as the current version, generate the new NSManagedObject subclasses, and make correspondant changes to the code.
create a mapping model and make the source points to the old datamodel version and the destination points to the new datamodel version
create custom migration policy and hook it up with one of the mappings inside the
mapping model
set up lightweight migration with "NSInferMappingModelAutomaticallyOption" equals to "NO".
test migration on simulator with the database coming from an older build.
I followed all and steps talked on apple documents and didn't make any changes on the entity schema after creating the mapping.. I tried to clean the DerivedData folder in xcode, and also I check the "VersionInfo.plist" which contains the correct versions of my datamodel. For the unchanged entities their hashkey are matching.
However I still get this error when I tried to do an migration.... Quite frustrated now.. Anyone can help to give me some guid on this problem?
Related
When a Core Data app is in early development, its Managed Object Model is often in constant flux. For each build, new Managed Objects and properties are added or deleted from the model.
When the Managed Object Model changes, the app will crash on next run with the error:
The model used to open the store is incompatible with the one used to create the store
The common advice in this situation is to delete the app from your device/simulator and re-run.
This works fine for developers using Xcode, but is annoying for non-technical stakeholders involved in the release process. It would be much preferable to not explain to the CEO or QA team that they must delete the app before installing that update from TestFlight. Or to field crashing bugs caused by this issue.
Once the models have been finalized a bit, we'll implement a real Core Data migration strategy.
In this dev phase, data loss is acceptable and expected.
This method will be removed before the app is released.
What's the easiest, lightweight, removable, debug way to "migrate" changes to the Managed Object Model between releases? This will likely be equivalent to "delete the app and re-run", but without needing to manually delete the app.
This should handle any and all changes to the Core Data stack, including adding and deleting Managed Objects and Properties.
In this scenario, I would check compatibility against the current model and then delete the SQLite database if a migration would have been required.
Consider using (in Objective-C)
// error, sourceStoreURL, theManagedObjectModel are valid
NSDictionary *storeMetadata=[NSPersistentStoreCoordinator metadataForPersistentStoreOfType: NSSQLiteStoreType
URL: sourceStoreURL error: &error];
BOOL storeIsCurrent=[theManagedObjectModel isConfiguration: nil
compatibleWithStoreMetadata: storeMetadata];
if (!storeIsCurrent)
{
// Alert user
// Delete on-disk store via sourceStoreURL
// (including -wal and -shm files if journaling enabled)
}
You can change the store URL when you change the model.
You can also do model versioning even for early development and then delete them all before you ship. This can also help your team learn the ins and outs of model versioning.
In Models context file it was mentioned
If you want Entity Framework to drop and regenerate your database
automatically whenever you change your model schema, add the following
code to the Application_Start method in your Global.asax file. Note:
this will destroy and re-create your database with every model change.
System.Data.Entity.Database.SetInitializer(new System.Data.Entity.DropCreateDatabaseIfModelChanges<HMS.Models.HMSContext>());
so I added this code in the Global.asax file inside protected void Application_Start().
Adding this line drops whole database when I do any changes in model class. Is there any alternate way to avoid this and still I can do Model changes?
i.e After performing changes in model when I rebuild and run my application, it drops my database and regenerate all the empty model tables. So I loose all my entered data and I want to preserve table data.
If you're using EF Code First 4.1, then, no, it will only drop and recreate. EF version 5 apparently supports dynamically changing the underlying database. It's in beta at the moment, but is available for production use if you want to try it out. You can install it through NuGet.
I am using Oracle with Entity Framework. The database ids are generated using triggers and sequences.
I want to set up Table-per-Type inheritance, as described here. I've set the "CourseId" to be StoreGeneratedPattern of "Identity".
Everything seems to be fine, except when I insert a row. The table representing the base class (in the walkthrough linked above, the Course table) gets a generated ID as expected.
However the table representing the inherited class (in the walkthrough linked above, the OnlineCourse table) has a row inserted with the CourseId set to zero. This violates the foreign key constraint.
I assume it's something to do with the sequence of inserts. I imagine it should work like:
Insert the Course row
Retrieve the newly created CourseId value
Insert the OnlineCourse, using the new CourseId
However, this isn't working because it's just using the default value of the CourseId (zero) to insert into OnlineCourse.
Any ideas how to fix this?
Since #Campinho hasn't written up his suggestion as an answer, I will do it.
This article has some background on a bug in StoreGeneratedPattern in VS2010.
One of very important features in ORM tools is an ability to get data auto-generated by a database during the entity persistence back to your application. The Entity framework supports this feature by setting StoreGeneratedPattern in the configuration of persisted property. The StoreGeneratedPattern setting is available in both SSDL (Store schema definition language) and CSDL (Conceptual schema definition language) parts of the EDMX file. CSDL configuration allows you defining the reloading behavior in the Model-first approach but SSDL part is responsible for generating correct SQL commands which will persist the entity and reload auto-generated properties. Unfortunately for a long time this was the source of all problems.
The feature was very hard to use because of the annoying bug in the Entity designer. When we set the property in the designer, the value was saved only in CSDL part but not in SSDL part of the EDMX file and the feature didn't work until we opened the EDMX file as XML and manually modified SSDL part. This solved the problem but only until we updated our model from the database. The update always deleted whole SSDL part including our manual change so we had to do it again. Any incremental development of our models become a big pain. The workaround was using mapped stored procedures for inserting and updating entities and mapping result sets (returning auto-generated data) from these stored procedures back to the entity. Finally this bug is solved in Visual Studio 2010 SP1 and we can use StoreGeneratedPattern without any problems because the value is correctly set in both CSDL and SSDL parts and it is not overwritten during updating from the database.
If you have this problem install KB2561001.
I installed the hotfix and changed the StoreGeneratedPattern to "None" then back to "Identity" for the relevant Ids. I could clearly see the SSDL section had been updated to indicate the new setting.
Then everything just worked! I'm not sure what's going to be in the patch from Oracle that they think will fix the problem.
I filed a service request with Oracle and it turns out this is a bug in their provider.
BUG 13724992 - EF: ENTITY NOT UPDATED AFTER SAVECHANGES USING STOREGENERATEDPATTERN
A fix for this bug will be released in an upcoming patchset. However, which patchset in will be included in and when that patchset will be released is currently unknown. I will let you know as soon as this fix will be released.
Using this guide I have created a static library (let's call it AppCore) that can be shared between the Mac OS X and iOS versions of one app. This static library uses Core Data and the point of it is to share the model part and schema versioning between different implementations.
I created a NSPersistentDocument based project that will depend on this AppCore. In this project I added a reference to the .xcdatamodel file. Then I created a simple table view with add/remove buttons to edit an array of one entity type with the assisted "new core data entity" item. This created an instance of NSArrayController and the required bindings for the add/remove behaviour.
Now, everything seems to work fine when I'm using the default class for the Core Data entities (NSManagedObject) and I'm able to add new rows using the +/- buttons. However, when I change the entity implementation class to a custom one, I'm getting an error
Failed to create new object
This seems to come from the NSArrayController and it seems to be unable to instantiate the required entity. I can, however, create one in the NSPersistentDocument subclass by:
[NSEntityDescription insertNewObjectForEntityForName:#"SomeEntity" inManagedObjectContext:[self managedObjectContext]]
What confuses me is why the instance of NSArrayController can't. If I understand correctly, the array controller is instructed to create an entity, not class and my guess is that the entities are created with the help of NSEntityDescription class. I could implement my own version of the array controller's add: but then again, it might be that here something is fundamentally wrong. I haven't touched the init:s and the custom entity class implementation is simply for convenience, to access the attributes directly.
I have tried changing the base SDK on the AppCore but without effect. Currently it uses the iOS version but I'm not sure how it should be. This is another question but if unrelated, I might ask it here on a separate question.
So, to summarize, why can't the NSArrayController create an instance of this entity?
Thanks in advance.
Update
This works if I add the SomeEntity class from the AppCore to the dependent project as a reference. This is not the most usable way since modifications to the AppCore has to be propagated to the dependatnt projects also.
Bingo. I missed the "-ObjC" flag for the dependant project's "other linker flags". Now everything works like a charm.
I've created an OSX app that uses the entity model builder and its related stuff, for simplicity consider the entity with only two NSString.
The app is in production and works fine, now I need to add new attributes to the existing entity (only one entity exists), but with new attributes the old saved files are not open, silently the app does't open them and the console doesn't contain any error/warning message.
I need to load old saved files, consider all new attributes are optionals and have defaults (also in code not only in model design)
All existing attributes continue to be present I've only added the new attrs.
How can I design applications able to work when the entity model change?
From OS X 10.5 onwards, there is data migration functionality to help you, as long as you make changes to the data model in a new version.
There is a good basic explanation and example here: http://www.timisted.net/blog/archive/core-data-migration/
and the Apple documentation is here: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreDataVersioning/Introduction/Introduction.html