CoreData could not fulfill a fault for

Question

I have a really annoying problem, which I just can\'t seem to get fixed.

I have a view when I send a message that gets saved to the Core Data, when thats done it asked

Answer 1

It is not really conceptually possible to "save" Core Data objects "in different rows". Remember, Core Data is an object graph and not a database.

If you want to "relocate" your sentence, the best way is to destroy it and recreate it. If you want to keep the old instance, just create a new one and then fill in the properties from the existing one.

For destroying, use

[self.context deleteObject:sentenceObject];

For recreating, use

Sentence *newSentence = [NSEntityDescription insertNewObjectForEntityForName:
  "Sentences" inManagedObjectContext:self.context];
newSentence.sentence = sentenceObject.sentence;
// fill in other properties, then
[self.context save:error];

If you would like to read up on this, look at "Copying and Copy and Paste" in the "Using Managed Objects" section of the "Core Data Programming Guide".

Answer 2

check the core data mechanism. "Faulting reduces the amount of memory your application consumes. A fault is a placeholder object that represents a managed object that has not yet been fully realized, or a collection object that represents a relationship:"

Answer 3

This happens because you are adding the "random message" to your new row before completion of fetching all your relations of the first call.

You can add a prefetch to your 1st call to avoid the lazy loading and the issue will be solved, I believe.

This is how we can do prefetching for the request:

[request setRelationshipKeyPathsForPrefetching:[NSArray arrayWithObjects:@"whatEverOfYourWillNumberOne",@"whatEverOfYourWillNumberTwo", nil]];

Hope that helps.

Answer 4

I fixed the error with changing NSFetchedResultsController's "cacheName" string to nil.

NSFetchedResultsController *aFetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:self.managedObjectContext sectionNameKeyPath:nil cacheName:@"Root"nil];

Answer 5

Hmm. Are you properly implementing concurrency following this guide? The problem you are seeing is a common one when using core data across multiple threads. Object was deleted in your "background context", while then it's being accessed by another context. Calling [context processPendingChanges] on your background context after the delete but before the save may help.

There is also a WWDC 2010 session (137) on optimizing core data performance that goes into deletes a bit.

When you execute a fetch Core Data returns a collection of objects matching the predicate you supplied. Those objects don't actually have their property values set yet. It's when you access a property that Core Data goes back to the store to "fire the fault" - populate the property with data from the store. "Could not fulfill a fault..." exceptions happen when Core Data goes to the store to get the property values for an object, but the object does not exist in the persistent store. The managed object context thought it should exist, which is why it could attempt the fault - which is where the problem is. The context that caused the exception to be thrown did not know that this object had been deleted from the store by something else (like another context).

Note the the above Concurrency Guide is now out of date, you should be using parent-child contexts and private queue concurrency rather than the older thread confinement model. Parent-child contexts are much less likely to run into "Could not fulfill a fault..." for many reasons. And please, file a documentation bug or use the feedback form to request that the concurrency guide be updated.