many\" relationship in Core Data with no inverse relationship and the delete rule set to both \"Nullify\" and \"No action\" (by that I mean I\'ve tried both with no avail)" />
开发者

Core Data not saving a relationship that has been deleted

I have a "to->many" relationship in Core Data with no inverse relationship and the delete rule set to both "Nullify" and "No action" (by that I mean I've tried both with no avail)

Basically I have a MergedStation whose property subStations points to many Station objects: MergedStation.subStation -->> Station

When I call [mergedStation addSubStationsObject:newStation]; (which is dynamically created) everything works great and a new station is added, everything is refreshed and saved correctly so that the next time I open the program, all is right.

However, when I call [mergedStation removeSubStationsObject:stationToRemove]; (also dynamically created), everything deletes correctly only for the current program session. If I close the program and open it again, it's like I didn't change anything. I have the exact same methods called after both the add and remove methods:

[self.managedObjectContext refreshObject:st开发者_运维技巧ation mergeChanges:YES];

[self.managedObjectContext processPendingChanges];

[self.managedObjectContext saveAndPrintErrors];

I have also tried different combinations of that above code to get it to work. Any help is appreciated!

Joe


It's unclear what you mean by "deletes correctly only for the current program session". The delete rule specifies what should happen when the relationship origin (the MergedStation) is deleted, not what happens when the relationship is broken. Removing the association should not delete any entity instance. If you want to delete the sub station, you must do that manually with -[NSManagedObjectContext deleteObject:].

On a side note, unless you have literally millions of substations (or billions on OS X), you should include the inverse relationship in your managed object model. Core Data is an object graph management framework and object graph management works best (is easiest) when all relationships are bidirectional. Core Data will do a lot of heavy lifting for your if you include the inverse. There's no need for you to make use of the inverse in your code; you can ignore it if you want. The only penalty you pay is a little memory. Until you can prove that extra memory use is detrimental to your code, you should keep the inverse relationship.


I have this same problem. What he means by "deletes correctly only for the current program sessions" is that if you examine the managed object before restarting the application it is in the state you want it to be in (in his case the SubStation object has been removed from the relationship collection).

I added the inverse relationship to the data model as suggested and everything worked magically. Nice to have working, but I would really like to know if there is a way around this without paying the extra memory penalty.


Ugh. I've spent too much time on a problem closely related to this. In my case, I was adding entities to a to-many relationship and losing those changes after relaunching my app. Adding the inverse relationship is what solved the problem, but I don't understand why. I mean, I see why inverse relationships are a good thing, but they should be mandated or at least default by Core Data if a one-way relationship is as useless as it seems to be.

Thanks to Erik P above for giving me the clue I needed! Add those inverse relationships!

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜