views:

218

answers:

3

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:station 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

+4  A: 

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.

Barry Wark
+1 for including the inverse. Core data expects it. Works better that way.
mmc
A: 

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.

Erik Petersen
A: 

I also have this problem. The relationship appears to be removed only for the current session. When the app is re-opened, the relationship is restored. I will try adding the inverse, but would like to know why it is required.

mkraken