StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
5861539
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2011-05-02T19:30:31.827
FavoriteCount
0
LastActivityDate
2011-05-03T15:49:41.950
LastEditDate
2011-05-03T15:49:41.950
LastEditorUserId
478744
OwnerUserId
478744
ParentId
5860370
PostTypeId
2
Score
2
ViewCount
0
LastEditorDisplayName
text
Body
--- Revised Answer --- Using NSFectchedResultsController appears to be your best bet. It will inform it's delegate when changes to it's MOC effect it's results. This negates the need for your view controller to know about or directly observe events from your background MOC. Here's the pattern I'd use with NSOperation worker processes. Store the background MOC in a NSOperationQueue subclass with a maxConcurrentOperationCount of 1. This ensures the operations will occur serially. <ul> <li>Subclass NSOperationQueue</li> <li>Add a property for the background MOC</li> <li>Implement the NSOperationQueue's MOC getter to lazily create the background MOC from the Persistent store and register the class responsible for the merging the context with the background MOC did save notification (Typically your AppDelegate or singleton)</li> <li>Unregister observations for the class and clean up the background MOC in dealoc</li> </ul> Create your NSOperationQueue subclass. Before adding operations, provision them with the background MOC from the queue's background MOC property. When scheduled, your operation will perform work with the background MOC and save. Perform the merge when the did save notification comes in on the observing class. After the merge, each fetched results controller using the foreground MOC will notify it's delegate when any changes had an impact on it results. This includes additions or deletions from the background MOC merge.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POApp Design: Handling Core Data w/ Background Contexts ; Merging w/ Notifications Filtered by MOC
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USScott Ahten
UserOwnerUserId
1. USScott Ahten
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. CONote that, in this case, only your NSOperationQueue subclass knows about the class handling the did save notification. Your NSOperation subclasses are handed an already configured MOC and do not interact with other instances beyond what is necessary to perform it's particular background task.
 singulars
 PostPostId
 PO
 UserUserId
 USScott Ahten

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.