Currently, I am developing an app to book cars. All booking related data are stored in an entity 'Bookings'. As some attributes of 'Bookings' or relationships between 'Bookings' and other enties are mandatory I decided to add all managedObjects of entity 'Bookings' to their own managedObjectContext. This context will also be stored in a separate variable to avoid losing it. This works fine unless I'll sign (enterprise store or adhoc) my app and deploy it. ARC is enabled.
Class Bookings interface
#interface Bookings : NSManagedObject {
#private
NSManagedObjectContext *mContext;
}
#end
Class Bookings implementation
#implementation Bookings {
+ (Bookings *)booking {
NSManagedObjectContext *context = [[NSManagedObjectContext alloc] initWithConcurrencyType:concurrencyType];
[context setPersistentStoreCoordinator:[self persistentStoreCoordinator]];
Bookings *object = (Bookings*)[[NSManagedObject alloc] initWithEntity:[self entityForName:pName] insertIntoMarenagedObjectContext:context];
[object setSomeReservationData:...];
...
// here I store the context in an ivar of my booking object
[object->mContext = context];
return object;
}
}
At this state the Booking object will not be saved!
Class BookingsVC
Bookings *booking = [Bookings booking];
NSLog(#"Context: %#", [booking managedObjectContext]);
Nothing saved or altered but context is null.
Console output on device (adhoc signed and deployed via iPhone-Configurator or Testflight)
... Context: (null)
Console output on simulator or device (adhoc signed but installed via Xcode)
... Context: <NSManagedObjectContext: 0x893c520>
So why does an unsaved managedObject lose its managedObjectContext and how can this be avoided? Is it a bug or the expected behavior?
Your context is nullified at the end of your function. see here
Your object is disowned by the context making all its properties null, in debug mode there exists an autorelease pool keeping the context from being deallocated.
Related
I have created CKQuerySubscriptions to monitor remote insertion, modification and deletion of CKRecords. For inserted and modified records this works well because I can query CloudKit for the affected CKRecord, get the associated NSManagedObject and then handle the insertion and modification from there.
For deleted CKRecords, this is a problem because by the time the notification has been fired, the CKRecord has already been removed from CloudKit. This means the fetch request to get the now deleted CKRecord fails, so I have no way to know which NSManagedObject was associated with the deleted CKRecord.
I don't know if I'm going about this all the wrong way and if there is an easier way to handle all of this!
This works, but it feels a bit clunky. There must be an easier way! But if not, if this code is useful to anybody else, feel free to comment if you want the code used in any of the helper methods not shown (e.g. in the +[CoreDataFunctions fetchRecordsForEntityType: withCloudIDs: completion:] method);
//Array to hold all cloudIDs of existing NSManagedObject instances
NSMutableArray *cloudIDs = [NSMutableArray array];
//Populate cloudIDs array with the IDs of the existing NSManagedObject instances
for (NSManagedObject *item in self.items) {
NSUUID *cloudID = [item valueForKey:#"cloudID"];
[cloudIDs addObject:cloudID];
}
//Array to hold remaining NSManagedObject instances (i.e. the ones which were not deleted)
NSMutableArray *remainingItems = [NSMutableArray array];
//Fetch all remaining CKRecords (i.e. the ones which were not deleted
[CoreDataFunctions fetchRecordsForEntityType:[self managedObjectMonitoringClass] withCloudIDs:cloudIDs completion:^(NSArray<CKRecord *> *results) {
//For each local NSManagedObject instance
for (NSManagedObject *item in self.items) {
//The cloudID for the local NSManagedObject instance
NSString *localCloudID = [[item valueForKey:#"cloudID"] UUIDString];
//For each CKRecord in CloudKit
for (CKRecord *record in results) {
//The cloudID for the remote CKRecord object
NSString *remoteCloudID = [record valueForKey:#"CD_cloudID"];
//If the local and remote cloudIDs match, the local NSManagedObject entity represents a CKRecord which still exists in CloudKit
//Add the NSManagedObject entity to the remainingItems array
if ([remoteCloudID isEqualToString:localCloudID]) {
[remainingItems addObject:item];
break;
}
}
}
//Array to hold NSIndexPath objects to be removed from the collectionView
NSMutableArray *indexPaths = [NSMutableArray array];
//For each NSManagedObject stored locally
for (NSManagedObject *item in self.items) {
//If the remainingItems array does not contain this NSManagedObject, it has been deleted from CloudKit
//Create and indexPath for this item and add it to the array
if (![remainingItems containsObject:item]) {
NSInteger index = [self.items indexOfObject:item];
[indexPaths addObject:[NSIndexPath indexPathForItem:index inSection:0]];
}
}
dispatch_async(dispatch_get_main_queue(), ^{
[[self TBcollectionView] performBatchUpdates:^{
//Set the local items array to whatever is remaining in CloudKit
self.items = remainingItems;
//Delete the indexPaths for the items which were deleted
[[self TBcollectionView] deleteItemsAtIndexPaths:indexPaths];
} completion:nil];
});
}];
I use subscriptions with remote notifications and CKFetchRecordZoneChangesOperation.
If the "application(didReceiveRemoteNotification:)" method is called, if build and fire a "CKFetchRecordZoneChangesOperation".
There are several completion handlers. One is for the updated records (add / modified) and there is a special one for deleted records.
This handler is called "recordWithIDWasDeletedBlock" and is called for each single record, which has been deleted, providing the recordID of the deleted record. With this information you should be able to process what you need.
This is a test on part of Apple's Core Data PG, which I quote here
You started with a strong reference to a managed object from another object in your application.
You deleted the managed object through the managed object context.
You saved changes on the object context.
At this point, the deleted object has been turned into a fault. It isn’t destroyed because doing so would violate the rules of memory management.
Core Data will try to realize the faulted 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.
So I setup a test project to see if it is the real case.
I'm using MagicalRecord to save some troubles creating MOCs, the code is based on a Core data model Class named "People"
#interface People : NSManagedObject
#property (nonatomic) int64_t userID;
#property (nullable, nonatomic, retain) NSString *name;
#end
In the test part, I wrap the MOCs MagicalRecord created into backgroundMOC and UIMOC so that those who are not familiar with MagicalRecord won't be confused.
UIMOC is BackgroundMOC's child and will merge backgroundMOC's changes by listening to NSManagedObjectContextDidSaveNotification backgroundMOC send out.
The "saveWithBlockAndWait" is just a wrapper around "performBlockAndWait". So here comes,
[[self backgroundMOC] MR_saveWithBlockAndWait:^(NSManagedObjectContext * _Nonnull localContext) {
People *people = [People MR_createEntityInContext:localContext];
people.userID = 1;
people.name = #"Joey";
}];
People *peopleInMainThread = [People MR_findFirstInContext:[self UIMOC]];
NSLog(#"Before delete, name = %#", peopleInMainThread.name);
[[self backgroundMOC] MR_saveWithBlockAndWait:^(NSManagedObjectContext * _Nonnull localContext) {
People *people = [People MR_findFirstInContext:localContext];
NSLog(#"Deleting, name = %#", people.name);
[localContext deleteObject:people];
}];
NSLog(#"After delete, name = %#", peopleInMainThread.name);
[[self UIMOC] save:nil];
NSLog(#"After save UIMOC, name = %#", peopleInMainThread.name);
The NSLog result is
Before delete, name = Joey //As expected
Deleting, name = Joey //As expected
After delete, name = Joey //Shouldn't it be nil already?
After save UIMOC, name = null //As expected
This result seems to state that Merge from parent MOC won't make model objects fault, which could lead to some hard-to-find bugs or instead tedious checking codes everywhere.
Again with the people object. I'll have to do things like this
- (void)codesInSeriousApp
{
[[self backgroundMOC] MR_saveWithBlockAndWait:^(NSManagedObjectContext * _Nonnull localContext) {
People *people = [People MR_createEntityInContext:localContext];
people.userID = 1;
people.name = #"Joey";
}];
__block People *people = nil;
[[self UIMOC] performBlockAndWait:^{
people = [People MR_findFirstInContext:[self UIMOC]];
}];
[self sendHttpRequestViaAFNetworking:^{
//this block is executed on main thread, which is AFNetworking's default behavior
if ([[self UIMOC] existingObjectWithID:people.objectID error:NULL])//[people isFault] would be NO here, and people's properties stay still.
{
//do something
}
else
{
//the people object is gone
//maybe some codes on another thread deleted it and save to the backgroundMOC
//the UIMOC merge the changes sent by notification, but the people object is still NOT FAULT!
}
}];
}
As far as I can tell, for any model non-fault object in a specific MOC, say MOCA, the object won't be fault until [MOC save:&error] called all the way down to the persistent store.
What really confuse me is, if Another MOC, already know that the object is fault by doing the saving chain, and MOCA merged changes that very MOC send out, how come the object in it is still non-fault?
Am I misunderstood or anything? Any reply would be appreciated.
Thx in advance :)
I have a Mac document-based app, using NSPersistentDocument for the document model.
When new document is created, the app adds some default data (several sport objects and user data) to the document in the initiWithType method.
- (id)initWithType:(NSString *)typeName error:(NSError **)outError {
self = [super initWithType:typeName error:outError];
NSManagedObjectContext *managedObjectContext = [self managedObjectContext];
[[SportManagement sharedManager] addDefaultSports:managedObjectContext];
[[UserManagement sharedManager] addDefaultUser:managedObjectContext];
[managedObjectContext processPendingChanges];
return self;
}
The app has an import function that imports data from some hardware, which runs in a thread, which I set up as follows (managedObjectContext is that of the NSPersistentDocument):
dispatch_async(dispatch_get_global_queue(0, 0), ^ {
NSManagedObjectContext *moc = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSConfinementConcurrencyType];
[moc setPersistentStoreCoordinator:[managedObjectContext persistentStoreCoordinator]];
Data is imported from the hardware into a number of NSManagedDataObject items. Each ManagedObject has a 'Sport' field, which needs to be populated with one of the sport objects created when the document was created.
However, none of the sport objects that were added in the - (id)initWithType:(NSString *)typeName error:(NSError **)outError exist in the new ManagedObjectContext in the thread (moc).
If I run the app, create a new document, then let the app sit idle for a minute-or-so, then try the import, then the Sport objects DO exist in the thread Managed Object Context.
How do I sync the new ManagedObjectContext in the thread with the main one from the NSPersistantDocument?
I've tried: [managedObjectContext processPendingChanges]; and [managedObjectContext setStalenessInterval];, but neither seem the solve this problem.
Interestingly, this doesn't appear to happen in Mac OS X 10.8, only in 10.7
Setup your "main" MOC to receive NSManagedObjectContextDidSaveNotification notifications, and merge the changes when the background MOC saves with -mergeChangesFromContextDidSaveNotification:.
EDIT
OK, it looks like you have made your changes in the MOC, but it is just a scratchpad. Until the data is actually saved to the persistent store, the persistent store does not know about the new data changes.
Thus, when you create your other MOC and connect it to the PSC, it does not know about those changes.
You can tell when autosave kicks in, because "after a while" it works.
I would try a manual save of the document after you create the initial content.
I make a program where I sometimes moves some anchor to another
When I move those anchors I would recompute distance of bizs nearby the 2 anchors (before and after anchors). The computation is done in background
I used this standard code to update stuff
+(void)commit {
// get the moc for this thread
[Tools breakIfLock];
NSManagedObjectContext *moc = [self managedObjectContext];
NSThread *thread = [NSThread currentThread];
DLog(#"threadKey commit%#" , [[self class]threadKey]);
if ([thread isMainThread] == NO) {
// only observe notifications other than the main thread
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(contextDidSave:) name:NSManagedObjectContextDidSaveNotification object:moc];
}
NSError *error;
if (![moc save:&error]) {
CLog(#"Error in Saving %#", error);
DLog(#"What the hell error is it");
}
else{
}
if ([thread isMainThread] == NO) {
[[NSNotificationCenter defaultCenter] removeObserver:self name:NSManagedObjectContextDidSaveNotification object:moc];
}
//[GrabClass StopNetworkActivityIndicatorVisible];
}
+(void)contextDidSave:(NSNotification*)saveNotification {
dispatch_async(dispatch_get_main_queue(), ^{
BadgerNewAppDelegate *delegate = [BNUtilitiesQuick appDelegate];
DLog (#"currentThreadinContextDidSave: %#",[self threadKey]);
NSManagedObjectContext *moc = delegate.managedObjectContext; //delegate for main object
CLog(#"saveNotification : %#",saveNotification);
[moc mergeChangesFromContextDidSaveNotification:saveNotification];
});
//[moc performSelectorOnMainThread:#selector(mergeChangesFromContextDidSaveNotification:) withObject:saveNotification waitUntilDone:YES];
}
I break point and see that distances did get updated. Everything is fine
However the NSFetchedResultsController fetchedObjects doesn't seem to get updated and still use the old value.
How can that be?
Also the
- (void)controllerWillChangeContent:(NSFetchedResultsController *)controller {
DLog(#"controllerWillChangeContent: %#", controller);
[self.tableViewA beginUpdates];
}
is never called even though the NSManagedObjectContext has changes.
Well actually I wasn't sure if the managedObjectContext has changed or not. How do I know? I mean will change in managedObjectContext ensure changes in fetchController.fetchedObjects.
There is no caching as far as I know. How can I be sure of that too?
The NSFetchedResultsController documentation for fetchedObjects property states:
The results array only includes instances of the entity specified by
the fetch request (fetchRequest) and that match its predicate. (If the
fetch request has no predicate, then the results array includes all
instances of the entity specified by the fetch request.)
The results array reflects the in-memory state of managed objects in
the controller’s managed object context, not their state in the
persistent store. The returned array does not, however, update as
managed objects are inserted, modified, or deleted.
Availability Available in iOS 3.0 and later.
I can't say what the appropriate workaround is. My first thought is to call performFetch: in controllerDidChangeContent: in the delegate implementation.
The fetchedObjects array appears to update simply by overriding controllerDidChangeContent: with an empty implementation. This is the case using both the iPad and the iPad simulator for iOS 5.1.
There's clearly some discrepancy between the documentation and what I have observed. I have no explanation. Sorry. I can only suggest that you perform the fetch in controllerDidChangeContent: just to be safe.
Background
I've got the following tree of objects:
Name Project
Users nil
John nil
Documents nil
Acme Project Acme Project <--- User selects a project
Proposal.doc Acme Project
12:32-12:33 Acme Project
13:11-13:33 Acme Project
...thousands more entries here...
The user can assign a group to a project. All descendants get set to that project.
This locks up the main thread so I'm using NSOperations.
I'm using the Apple approved way of doing this, watching for NSManagedObjectContextDidSaveNotification and merging into the main context.
The Problem
My saves have been failing with the following error:
Failed to process pending changes before save. The context is still dirty after 100 attempts. Typically this recursive dirtying is caused by a bad validation method, -willSave, or notification handler.
What I've Tried
I've stripped all the complexities of my app away, and made the simplest project I could think of. And the error still occurs. I've tried:
Setting the max number of operations on the queue to 1 or 10.
Calling refreshObject:mergeChanges: at several points in the NSOperation subclass.
Setting merge policies on the managed object context.
Build and Analyze. It comes up empty.
My Question
How do I set relationships in an NSOperation without my app crashing? Surely this can't be a limitation of Core Data? Can it?
The Code
Download my project: http://synapticmishap.co.uk/CDMTTest1.zip
Main Controller
#implementation JGMainController
-(IBAction)startTest:(id)sender {
NSManagedObjectContext *imoc = [[NSApp delegate] managedObjectContext];
JGProject *newProject = [JGProject insertInManagedObjectContext:imoc];
[newProject setProjectName:#"Project"];
[imoc save];
// Make an Operation Queue
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
[queue setMaxConcurrentOperationCount:1]; // Also crashes with a higher number here (unsurprisingly)
NSSet *allTrainingGroupsSet = [imoc fetchAllObjectsForEntityName:#"TrainingGroup"];
for(JGTrainingGroup *thisTrainingGroup in allTrainingGroupsSet) {
JGMakeRelationship *makeRelationshipOperation = [[JGMakeRelationship alloc] trainGroup:[thisTrainingGroup objectID] withProject:[newProject objectID]];
[queue addOperation:makeRelationshipOperation];
makeRelationshipOperation = nil;
}
}
// Called on app launch.
-(void)setupLotsOfTestData {
// Sets up 10000 groups and one project
}
#end
Make Relationship Operation
#implementation JGMakeRelationshipOperation
-(id)trainGroup:(NSManagedObjectID *)groupObjectID_ withProject:(NSManagedObjectID *)projectObjectID_ {
appDelegate = [NSApp delegate];
imoc = [[NSManagedObjectContext alloc] init];
[imoc setPersistentStoreCoordinator:[appDelegate persistentStoreCoordinator]];
[imoc setUndoManager:nil];
[imoc setMergePolicy:NSMergeByPropertyStoreTrumpMergePolicy];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(mergeChanges:)
name:NSManagedObjectContextDidSaveNotification
object:imoc];
groupObjectID = groupObjectID_;
projectObjectID = projectObjectID_;
return self;
}
-(void)main {
JGProject *project = (JGProject *)[imoc objectWithID:projectObjectID];
JGTrainingGroup *trainingGroup = (JGTrainingGroup *)[imoc objectWithID:groupObjectID];
[project addGroupsAssignedObject:trainingGroup];
[imoc save];
trainingGroupObjectIDs = nil;
projectObjectID = nil;
project = nil;
trainingGroup = nil;
}
-(void)mergeChanges:(NSNotification *)notification {
NSManagedObjectContext *mainContext = [appDelegate managedObjectContext];
[mainContext performSelectorOnMainThread:#selector(mergeChangesFromContextDidSaveNotification:)
withObject:notification
waitUntilDone:YES];
}
-(void)finalize {
appDelegate = nil;
[[NSNotificationCenter defaultCenter] removeObserver:self];
imoc = nil;
[super finalize];
}
#end
#implementation NSManagedObjectContext (JGUtilities)
-(BOOL)save {
// If there's an save error, I throw an exception
}
#end
Data Model
Update 1
I've experimented some more, and even without the merge, the exception is still thrown. Just saving the managed object context in another thread after modifying a relationship is enough.
I have a shared persistent store coordinator with the app delegate. I've tried making a separate NSPersistentStoreCoordinator for the thread with the same URL as my data store, but Core Data complains.
I'd love to suggestions on how I can make a coordinator for the thread. The core data docs allude to there being a way of doing it, but I can't see how.
You are crossing the streams (threads in this case) which is very bad in CoreData. Look at it this way:
startTest called from a button (is IBAction, assuming button tap) on Main thread
Your for loop creates a JGMakeRelationship object using the initializer trainGroup: withProject: (this should be called init, and probably call super, but that's not causing this issue).
You create a new managed object context in the operation, on the Main thread.
Now the operation queue calls the operations "main" method from a worker thread (put a breakpoint here and you'll see it's not on the main thread).
Your app goes boom because you've accessed a Managed object Context from a different thread than the one you created it on.
Solution:
Initialize the managed object context in the main method of the operation.