Re: CoreData could not fulfill a fault
Re: CoreData could not fulfill a fault
- Subject: Re: CoreData could not fulfill a fault
- From: Bill Bumgarner <email@hidden>
- Date: Thu, 12 May 2005 09:23:29 -0700
On May 12, 2005, at 3:13 AM, Pierre Bernard wrote:
Anybody know which operation may produce the following error:
"CoreData could not fulfill a fault" ?
This can happen in at least two situations [off the top of my head]:
First:
- start with a -retain'd reference to a managed object
- delete the managed object via the managed object context
- save changes on the object context
At this point, the deleted object has been turned into a fault. It
is isn't destroyed because, obviously, doing so would violate the
rules of retain/release.
- try to grab an attribute or relationship from the previously
retain'd reference
Core Data will try to fault the now-a-fault managed object but will
fail to do so because the object has been deleted from the store.
That is, there is no longer an object with the same global ID in the
store.
Second:
- delete an object from a managed object context
- fail to break all relationships from other objects to that object
- save changes
At this point, if you try to fire the relationship from some other
object to that object, it may fail. I say "mail" because it depends
on the details of the configuration of the relationship as that
affects how the relationship is stored.
The delete rules for relationships only affect relationships from the
source object to other objects (including inverses). Without
potentially fetching tons and tons of objects, possibly without
reason, there is no way for Core Data to efficiently clean up the
relationships to the object.
Keep in mind that a Core Data object graph is most definitely
directional. That is, a relationship has a source and a
destination. Following a source to a destination does not
necessarily mean that there will be an inverse relationship. So, in
that sense, you need to expend the effort to ensure that you are
properly maintaining the object graph across deletes.
This sounds scary but, in practice, a well designed object graph
will not require that much manual post-deletion clean up. If you
consider that most object graphs have 'entry points' that act as a
sort of root node for navigating the graph and that most insertion/
deletion events are rooted at those nodes just like fetches, then
delete rules will take care of most of the work for you. Similarly,
since smart groups and other "casual" relationships are generally
best implemented with fetched properties, various ancillary
collections of entry points into the object graph will generally not
need to be maintained across deletes because fetched relationships
have no notion of permanence when it comes to objects found via the
fetched relationship.
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden