Ok,
I have an iphone program that is simply a tableview using the CoreData to load, I have added a simple data loading class that is passed the NSManagedObjectContext, reads in the data from a file I want loaded into the database, instantiates objects using the managedObjectContexts as needed, loads them with the data read in, and then calls the managedObjectContext save when all the data is read. This as expected saves the created objects in the database.
Execution is then returned to my TableViewController which continues preparing itself for view.
I have not released it or done anything else with this context, just passed a reference to it to the data loading class, created objects using it in that class and then called SAVE to store those objects.
Control is passed back to the tableViewController and it does its thing to get itself displayed. Unfortunately, this dies with an EXC_BAD_ACCESS meaning I'm attempting to access somewhere a dead object.
So, I trace through the code and find the following appears to be the culprit:
I have a save method in the tableviewcontroller class that is wrapped in a hasChanges check on the NSManagedObjectContext, that actually passes this test and attempts to execute another save . No change to the managedObject has occurred since the time I executed the SAVE call in the dataload class, so I have no idea why this check would pass. But it does, and the object attempts to SAVE, and then dies.
Now my assumption is that this save is attempting to save the objects created by the load class, and have already been saved by its direct save call, and memory management had released them, but this second "save" is trying once again to find them, and of course failing.
Now, I "fixed" the problem by wrapping my save method in the dataload class with a hasChanges check before performing the save. Now the TableViewController class properly recognizes no changes are waiting when it performs its hasChanges check and doesn't try to resave data its already saved.
Now here's my question(s),
First and foremost, why is the hasChanges coming back true, when I've already saved them? There have been no changes since then, we are utilizing the exact same context, so why does it think it has changes to save? There are no UNCOMMITTED changes, they were all saved in the direct save call.
Second why would wrapping the previous save in a hasChanges check affect the result of the second hasChanges call result?
Is there a bug in the hasChanges logic? Am I just doing something grotesquely wrong? I have no issues wrapping every save I make in a hasChanges conditional first, but to my mind an object has uncommitted changes or it doesn't. Shouldn't a save clear the flag saying their are uncommitted changes on its own?