When I try to add a new ManagedObject to an existing relationship of an entity using the Core Data generated method "addArticleObject", a fault is fired for the articles relationship. Is it possible to add an object to a relationship without causing a fault to fire for the existing objects in the relationship?
I'm not sure I'm understanding your question exactly, but if you modify your core data model, as long as you go on the simulator and delete your app, then rerun it (so it regenerates everything), then you should be fine. You also might have to delete and recreate your NSManagedObject classes, but that's a quick thing also.
If you've altered the structure of your Core Data model, unless you've done so with a migration you'll need to clear the previous version from the Simulator and any handsets you're testing on. The error which occurs if you don't isn't particularly helpful.
Use the 'Reset contents & settings' option in the Simulator, and delete and reinstall the app on a phone. Simply rerunning the app isn't enough.
It seems that it is not possible to add objects to a many-to-many inverse relationship in Core Data without having both objects in the relationship in memory. I'm sure there must be a good reason for that requirement, which I would like to know. This has however caused me to have to refactor the database and all associated code
Related
I am current running EF 4.3.1 which was recently upgraded from 4.1, using a database first model. I also have my model and objects spread across different assemblies.
As I'm developing however, I'm finding the entity framework almost impossible to live with, because despite having the option "update model from database", seldom can I do so without causing the designer to fire up errors.
If I add an index to a table, create a fk relationship, there's a good chance that the designer will show a 'object null reference exception' when I try do do anything with the database afterwards. To make it even harder, the error message is exactly that vague, not pointing to what it actually could be.
I have asked a question elsewhere and the response I got back was to recreate the edmx. Surely not when I have 60 to 80 entities?
I can't believe that I'm the only one with the issue, and i can't believe any developer could live with the situation, but I can't find information anywhere as to what the issue is - if in fact its not 'by design'.
Can anyone help?
The reason for the crash is due to the de-sync'd relationship between the edmx and the dbcontext.
When changes, or even refresh is applied to the edmx you MUST run the custom tool update before exiting the project. Failure to do this will result in a corrupt edmx., which I have yet not managed to fix without restoring/recreating it.
Whilst this is in your hands most of the time, obviously there are occasions when this is outside of your control and should be something managed by the framework rather than depend on your ability to remember and the will of god. Hopefully longer term this will be included in the framework.
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 the older version of the core data model of the released app. Now, in the next version of the app, I am migrating the core data model to new model. Is there a way to get the attribute values from the old model before actually migrating to the new version of the model or is there possibly a way to know if the migration is to be occurred.
When you migrate, Core Data actually moves existing values for you. If you're doing a relatively simple migration, such as adding or removing some properties, Core Data does its best to make the move as seamless as possible. In many cases, you won't need to make any changes other than set your new model. See my answer here for more.
Yes, it is possible.
To get the attribute values from the old model you'll need to create custom entity migration policies (NSEntityMigrationPolicy subclasses). Then in -createDestinationInstancesForSourceInstance:entityMapping:manager:error: you'll receive source instance, and it is completely up to you how to create destination instances from source instances.
There is a method to check if a given store is compatible with store coordinator model: -[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:].
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.
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.