I am creating an NSManagedObject subclass (Group), set some properties/attributes and then pass it on to a different object (where it is stored in a strong property). This object takes some of the Group information and sends it to a server over an instance of GCDAsyncSocket. The server responds with some information that I then want to store as an attribute of the Group. However, by the time the server responds back and GCDAsyncSocket's delegate is called, all of the Group's attributes are set to nil.
Since I'm using UIManagedDocument for my Core Data implementation, when the auto-save kicks in, I get the following error:
Error Domain=NSCocoaErrorDomain Code=134030 "The operation couldn’t be
completed. (Cocoa error 134030.)" UserInfo=0x1f5c96f0
{NSAffectedObjectsErrorKey=(
"<Group: 0x1f5aa300> (entity: Group; id: 0x1f5c73b0 ;
data: {<entities here, nil values>})" ), NSUnderlyingException=Cannot
update object that was never inserted.}
However, I know that the objects are inserted. It did some research and found a lot of problems that were related to using two or more different managed object contexts, but that is not my problem (as the only managed object context I ever get is from the UIManagedDocument).
Some code:
#property(nonatomic, strong) Group *currentGroup;
// ....
- (void)storeGroupOnServer:(Group *)group {
self.currentGroup = group;
NSLog("%#", self.currentGroup); // correct value for name attribute
[self.currentGroup addObserver:self forKeyPath:#"name" options:NSKeyValueObservingOptionNew context:NULL];
// do some other things, unrelated to this problem
// write data to socket
}
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {
// This method is called before the socket returns with response data
NSLog(#"%#", (Group *)object.name); // incorrect value for name attribute (nil)
NSLog(#"%#", self.currentGroup); // same as above
}
Anybody who has a clue what I'm doing wrong here?
Related
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 would like to use the item that has been just been saved in the completion block of Magical Record saveWithBlock method. For example:
//Get the ID of an existing NSManagedObject to use in the save block (if it exists)
NSManagedObjectID *objectRef = [self.object objectID];
[MagicalRecord saveWithBlock:^(NSManagedObjectContext *localContext){
//This method either loads an existing object and makes changes or creates a new entity in localContext
NSManagedObject *itemToSave = [self prepareItemInContext:localContext WithID: objectRef];
} completion:^(BOOL success, NSError *error) {
if (success) {
//here I want to get at the object 'itemToSave' that was either created in the save block (with a new objectID) or updated (with the ID objectRef)
Well, you need to have a reference to your external context to load the object with that ID:
NSManagedObjectContext *outsideContext = //...
NSManagedObjectID *objectID = //...
[MagicalRecord saveWithBlock:^(NSManagedObjectContext *localContext) {
} completion:^(BOOL success, NSError *error) {
NSManagedObject *newlySavedObject = [outsideContext existingObjectWithID:objectID];
//...do stuff here
}];
Generally, however, I would discourage this usage. I would instead recommend keeping any predicates or means of reloading your data set handy, and dump and refetch fresh data from the store. This will give you proper object references. Another, more precise way of updating objects in other contexts is to listen to the NSManagedObjectContextDidSaveNotification and merge this updates into your context. From there, your data will be "refreshed" and as long as you're KVO'ing a property, or using a NSFetchedResultsController with a delegate, your updates will propagate to the UI (or other destination).
Either just use self.object or, if you create a new object and insert it (presumably because objectRef is nil) then you should get the corresponding new object from the main thread context and use that.
How you do that shuffle is the interesting part. It isn't exactly clear why you're using a background context at the moment so you can also consider changing that, which removes all of the complexity.
If you need to keep the background context then you need to decide on how to get that data back to the main thread. Generally, you could use performBlockAndWait: inside your current block to get the new object from the main context and then store it into a property on your class so you can use it in the completion block. This would be setting the self.object property.
I'm using AFNetworking and MagicalRecord (the current develop branch) and I'm trying to figure out how to import a lot of objects which are dependent on each other. Each resource/entity has multiple pages worth of downloads. I have a class managing the downloads for a given entity and saving them using MagicalDataImport (which has been amazing).
I believe my issue is that the imports aren't happening on the same thread. So I think what is happening is:
In one thread, EntityA is getting saved properly and propagated to the parent entity.
Then in another thread, EntityB is being saved, and along with it it's relationship to EntityA is built. That means a blank (fault?) object is being created. Then when it gets propagated to the parent entity, I believe EntityA is overwriting the EntityA that is there. Thus I'm left with some objects that don't have all of the attributes.
At least, I think that is what is happening. What I'm seeing via the UI is actually that the relationships between entities aren't always built correctly.
My end goal is to get the entire download/import process to be done in the background, not effecting the UI at all.
Here is my AFJSONRequest:
AFJSONRequestOperation *operation = [AFJSONRequestOperation
JSONRequestOperationWithRequest:request
success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON)
{
[self saveResources:[JSON objectForKey:#"data"]];
}
failure:^(NSURLRequest *request, NSHTTPURLResponse *response, NSError *error, id JSON)
{
DLog(#"%#",error.userInfo);
[self.webService command:self didFail:error.localizedDescription];
}];
[operation setQueuePriority:self.priority];
And it calls saveResources::
- (void)saveResources:(NSArray*)resources {
BOOL stopDownloads = [self stopDownloadsBasedOnDate:resources];
if ([resources count] > 0 && !stopDownloads){
self.offset = #([offset intValue] + [resources count]);
[self send];
}
[MagicalRecord saveWithBlock:^(NSManagedObjectContext *blockLocalContext) {
[self.classRef MR_importFromArray:resources inContext:blockLocalContext];
} completion:^(BOOL success, NSError *error) {
if (error){
// ... handle errors
}
else {
// ... handle callbacks
}
}];
}
This kicks off another download ([self send]) and then saves the objects.
I know by default AFNetworking calls the callback in the main queue, and I've tried setting the SuccessCallbackQueue/FailureCallbackQueue to my background thread, but that doesn't seem to solve all the issues, I still have some relationships going to faulted objects, though I think I do need to do that to keep everything going in a background thread.
Is there anything else I need to call in order to properly propagate these changes to the main context? Or is there a different way I need to set this up in order to make sure that all the objects are saved correctly and the relationships are properly built?
Update
I've rewritten the issue to try to give more clarification to the issues.
Update
If you need more code I created a gist with (I believe) everything.
I ended up having this exact same issue a few days ago. My issue was I had received a customer record from my API with AFNetworking. That customer could have pets, but at this point I didn't have the petTypes to correspond to the customers pet record.
What I did to resolve this was create a transformable attribute with an NSArray which would temporarly store my pets until my petTypes were imported. Upon the importation of petTypes I then triggered an NSNotificationCenter postNotification (or you can just do the pet import in the completion).
I enumerated through the temporary transformable attribute that stored my pet records and then associated the with the petType
Also I see you are doing your import inside of a save handler. This is not needed. Doing your MR_importFromArray will save automatically. If you are not using an MR_import method then you would use the saveToPersistentStore methods.
One thing is I don't see where you are associating the relationships. Is EntityB's relationship to EntityA being sent over via JSON with the EntityA objecting being in EntityB?
If so then this is where the relationship is getting messed up as it is creating / overwriting the existing EntityA for the one provided in EntityB. My recommendation would be to do something like this.
NSArray *petFactors = [responseObject valueForKeyPath:#"details.items"];
NSManagedObjectContext *currentContext = [NSManagedObjectContext MR_context];
Pets *pet = [Pets MR_findFirstByAttribute:#"id" withValue:petId inContext:currentContext];
pet.petFactors = nil;
for (id factor in petFactors) {
[pet addPetFactorsObject:[PetFactors MR_findFirstByAttribute:#"id" withValue:[factor valueForKey:#"factorId"]]];
}
[currentContext MR_saveToPersistentStoreWithCompletion:^(BOOL success, NSError *error) {
if (success) {
NSLog(#"SAVED PET FACTORS");
[[NSNotificationCenter defaultCenter] postNotificationName:kPetFactorsSavedSuccessfully object:nil];
} else {
NSLog(#"Error: %#", error);
}
}];
I'm putting this as an answer, though I'm not 100% sure if this is your issue or not. I think the issue stems from your localContext. Here is a sample web request method from an app we wrote that uses data importing, you may be able to use it as an example to get yours working.
Note that the AFNetworking performs its completion block on the main thread, then the MagicalRecord saveInBackground method switches back to a background thread to do the importing and processing, then the final MR completion block performs the handler block on the main thread again. The localContext that's used to import is created/managed by the saveInBackground method. Once that method is complete the context is saved and merged with the app's main context and all the data can then be accessed.
- (void)listWithCompletionHandler:(void (^)(BOOL success))handler{
[[MyAPIClient sharedClient] getPath:#"list.json" parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject){
NSString *statusString = [responseObject objectForKey:#"status"];
// Handle an error response
if(![statusString isKindOfClass:[NSString class]] || ![statusString isEqualToString:#"success"]){
// Request failure
NSLog(#"List Request Error: %#", statusString);
NSLog(#"%#", [responseObject objectForKey:#"message"]);
if(handler)
handler(NO);
return;
}
NSArray *itemsArray = [responseObject objectForKey:#"items"];
[MagicalRecord saveInBackgroundWithBlock:^(NSManagedObjectContext *localContext){
// Load into internal database
NSArray *fetchedItems = [Item importFromArray:itemsArray inContext:localContext];
NSLog(#"Loaded %d Items", [fetchedItems count]);
} completion:^{
if(handler)
handler(YES);
}];
} failure:^(AFHTTPRequestOperation *operation, NSError *error){
NSLog(#"Fail: %#", error);
if(handler)
handler(NO);
}];
}
I have three entities:
Notification
PlanDate
User
Relationships:
Notification has to-one relationship with PlanDate
Notification also has to-many relationship with User
Code:
NSLog (#"Selected Object From Detail ViewDidLoad %#", managedObject);
NSManagedObject *planDateObject = ((PlanDate *)[managedObject valueForKey:#"plandate"]);
NSLog(#"planDateObject %#", planDateObject);
NSString *recipientUserName = [planDateObject valueForKey:#"recipientUserName"];
NSLog(#"recipientUserName: %#", recipientUserName);
Here is the log:
2013-08-21 12:26:50.349 Time[5018:c07] Selected Object From Detail ViewDidLoad <Notification: 0xa58ee70> (entity: Notification; id: 0xb2a5480 <x-coredata://C0FB76AD-19EB-42BA-981A-F99DD6DCF6C7-5018-0000101A36CFA3D1/Notification/p0B2ABAC1-77F3-4F46-B14D-34652F148B37> ; data: {
appType = 1;
invitationType = PlanDate;
lastmoddate = "2013-08-21 17:42:42 +0000";
"notification_id" = "0B2ABAC1-77F3-4F46-B14D-34652F148B37";
plandate = "0xa1c9350 <x-coredata://C0FB76AD-19EB-42BA-981A-F99DD6DCF6C7-5018-0000101A36CFA3D1/Notification/p1C004B2B-F1DA-4EE0-9FAC-0A89E0DBCDB7>";
users = "<relationship fault: 0xb2aa210 'users'>";
})
2013-08-21 12:26:50.350 Time[5018:c07] planDateObject <Notification: 0xb292800> (entity: Notification; id: 0xa1c9350 <x-coredata://C0FB76AD-19EB-42BA-981A-F99DD6DCF6C7-5018-0000101A36CFA3D1/Notification/p1C004B2B-F1DA-4EE0-9FAC-0A89E0DBCDB7> ; data: <fault>)
2013-08-21 12:26:53.406 Time[5018:c07] *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<Notification 0xb292800> valueForUndefinedKey:]: the entity Notification is not key value coding-compliant for the key "recipientUserName".'
There is indeed an attribute "recipientUserName" with a Value. I have tried other attributes that produce the same log.
Why the error? Why is the Data shown as fault when I'm trying to access its attribute?
EDIT
The error message says that there is not actually an attribute named recipientUserName on the entity Notification. Let's run through your results to see what happened. First you do this:
NSLog (#"Selected Object From Detail ViewDidLoad %#", managedObject);
And the result is this:
2013-08-21 12:26:50.349 Time[5018:c07] Selected Object From Detail ViewDidLoad <Notification: 0xa58ee70> (entity: Notification; id: 0xb2a5480 <x-coredata://C0FB76AD-19EB-42BA-981A-F99DD6DCF6C7-5018-0000101A36CFA3D1/Notification/p0B2ABAC1-77F3-4F46-B14D-34652F148B37> ; data: {
appType = 1;
invitationType = PlanDate;
lastmoddate = "2013-08-21 17:42:42 +0000";
"notification_id" = "0B2ABAC1-77F3-4F46-B14D-34652F148B37";
plandate = "0xa1c9350 <x-coredata://C0FB76AD-19EB-42BA-981A-F99DD6DCF6C7-5018-0000101A36CFA3D1/Notification/p1C004B2B-F1DA-4EE0-9FAC-0A89E0DBCDB7>";
users = "<relationship fault: 0xb2aa210 'users'>";
})
This says that managedObject is an instance of Notification, and that Notification's attributes are:
appType
invitationType
lastmoddate
notification_id
plandate
users
The plandate attribute is actually a to-one relationship. According to the log message, the object at the other end of this relationship is another instance of Notification (as indicated by the x-coredata managed object ID representation). I'm guessing you meant this to be an instance of PlanDate, but your log message says that this isn't what you actually have there.
Next you do this:
NSManagedObject *planDateObject = ((PlanDate *)[managedObject valueForKey:#"plandate"]);
NSLog(#"planDateObject %#", planDateObject);
And the result is:
2013-08-21 12:26:50.350 Time[5018:c07] planDateObject <Notification: 0xb292800> (entity: Notification; id: 0xa1c9350 <x-coredata://C0FB76AD-19EB-42BA-981A-F99DD6DCF6C7-5018-0000101A36CFA3D1/Notification/p1C004B2B-F1DA-4EE0-9FAC-0A89E0DBCDB7> ; data: <fault>)
So if you had any doubt about what type planDateObject is, this nails it. It's most definitely an instance of the Notification entity. The typecast to PlanDate doesn't mean anything here. The fact that the data is shown as <fault> is normal here, because at this point you haven't tried to access any of its attributes.
Finally you do this:
NSString *recipientUserName = [planDateObject valueForKey:#"recipientUserName"];
You're trying to get the value of the recipientUserName attribute. But we already know that planDateObject is a Notification, and that Notification does not have an attribute with that name. So, you get an exception from trying to access a nonexistent key.
So, if your PlanDate entity has an attribute named recipientUserName, then your problem is that the plandate relationship is pointing at the wrong object. If PlanDate does not have that attribute, you have more complex problems that can't be solved from the information you've provided.
I am creating a table view controller for an app that manages position assignments for a team. The sections with headers for defense, center, and offense for example will have names in them if a position Entity exists with that positionProperty. If that person is removed though through swiping, they become an alternate entity with same positionProperty.
I am trying to have the alternates for each position display when the edit button is tapped. Much like extra contact details appear when you edit a contact in the contacts app.
I have a fetchedResultsController returning the parent entity for alts/positions keyed by the positionProperty to define sections. (This may be the wrong way to do this... I am new to Core Data).
In setEditing:WithAnimation I have done the following. Attempting to search my fetched results and if any objects are of type Alternate, display that row. So in the enumeration, if it is type alternate I tried to call IndexPathForObjects:alt. This just returned nil...
if(editing){
[self.tableView beginUpdates];
for (MCAlternate *alt in fetchedResultsController.fetchedObjects) {
if ([alt isKindOfClass:[MCAlternate class]]) {
NSLog(#"The alternate is: %#", alt);
// This is where the error is trying to get indexPathForObject
NSIndexPath *index = [fetchedResultsController indexPathForObject:alt];
[self.tableView insertRowsAtIndexPaths:[NSArray arrayWithObject:[index] withRowAnimation:UITableViewRowAnimationLeft];
}
}
[self.tableView endUpdates];
}
I have checked if the object exists in the results. It does. I have also tried called the getindexpath in a place with the object was just created by calling objectAtIndexPath and it still came back nil.
any suggestions are appreciated, Thanks!
Maybe you are not using your fetched results controller as it is foreseen. Your frc should fetch all the data to populate the table view.
You can still achieve the dynamic table content by tweaking your table view datasource methods. Suppose you are fetching the entity "Position" and the position object in question has a to-many attribute of entity "MCAlternate" called "alternates". You would then expand a certain section as follows:
-(void)expandSectionForPosition:(Position *)position {
int row = 0;
int section = [[frc indexPathForObject:position] section];
for (MCAlternate *alt in position.alternates) {
// update your datasource - e.g. by marking the position as
// "expanded"; make sure your numberOfRowsInSection reflects that
[_tableView insertRowsAtIndexPaths:#[[NSIndexPath
indexPathForRow:i++ inSection:section]]
withRowAnimation:UITableViewRowAnimationLeft];
}
}
Your class check is not logical - you are casting as MCAlternate in the for loop anyway. Your call or getting the index path fails, because you typically do not have a separate fetched results controller.