0

I've implemented a simple REST request in a structure as follows:

RKManagedObjectRequestOperation *operation = [[RKManagedObjectRequestOperation alloc] initWithRequest:request responseDescriptors:@[responseDescriptor]];
operation.targetObject = nil;
operation.savesToPersistentStore = YES;
operation.managedObjectContext = [RKManagedObjectStore defaultStore].mainQueueManagedObjectContext;
operation.managedObjectCache = [RKManagedObjectStore defaultStore].managedObjectCache;

[operation setCompletionBlockWithSuccess:^(RKObjectRequestOperation *operation, RKMappingResult *result) {
    // Handle success   
} failure:^(RKObjectRequestOperation *operation, NSError *error) {
    // Handle failure
}];

How can I modify the code so that:

  • in case of success I need the related entity on DB to be emptied and its content replaced with the new one arrived from the WS (no update, entire content replaced);
  • in case of failure nothing should happen and the entity on DB must remain as it is.

In order to delete the DB entity, before the operation I would do as reported here: Core Data: Quickest way to delete all instances of an entity, but that would empty the entity no matter what the WS answer is.

Any help is really appreciated, Thanks a lot, DAN

EDIT1:

As suggested by @Wain, I've added a fetch request block to the operation like this:

RKFetchRequestBlock fetchRequestBlock = ^NSFetchRequest *(NSURL *URL)
{
    NSFetchRequest *fetchRequest = [NSFetchRequest fetchRequestWithEntityName:@"EntityToBeUpdated"];
    fetchRequest.sortDescriptors = @[ [NSSortDescriptor sortDescriptorWithKey:@"order" ascending:NO] ];
    return fetchRequest;
};

operation.fetchRequestBlocks = @[fetchRequestBlock];
operation.deletesOrphanedObjects = YES;

but the result doesn't change: the items on db are not updated or deleted.

Community
  • 1
  • 1
DAN
  • 919
  • 1
  • 6
  • 23

1 Answers1

1

RestKit is based around updating rather than replacing. As such your requirement is hard to manage during mapping. You could consider:

  1. Have RestKit create a new instance and delete the old one in the success block - duplicate objects for a short time.
  2. Use a dynamic mapping to check the response before mapping is started to decide wether to delete or not - kinda hacky.
  3. Have the JSON response contain values for all keys so everything will be overwritten.

From an error point of view, if the error is returned with an HTTP status code and you have no response descriptor for that code then RestKit will change nothing.


Based on your comment below, you are actually looking for orphaned item deletion. This is done using fetch request blocks. See section Fetch Request Blocks and Deleting Orphaned Objects here. You don't need a predicate, just a fetch request.

David
  • 9,635
  • 5
  • 62
  • 68
Wain
  • 118,658
  • 15
  • 128
  • 151
  • Hi Wain, the WS answers with a response like this: "items": [{ "id" : "1", "type": "type1", "label": "label1", "order": "1" },{ "id" : "2", "type": "type2", "label": "label2", "order": "2" } ] which could change to: "items": [{ "id" : "1", "type": "type5", "label": "label5", "order": "1" } ] which means that the first item must be updated with new vales and the second one deleted. Would it be possible or I have to empty the entity as mentioned above? – DAN Jan 23 '14 at 15:46
  • Thanks for your suggestion about using fetch request block. In order to use it shall I leave all the code as written above and just add operation.fetchRequestBlocks = ... ? – DAN Jan 23 '14 at 23:37
  • 1
    I'd use an object manager rather than an operation, it's easier and offers more features. – Wain Jan 23 '14 at 23:44
  • As it is not clear to me how to achieve this with an object manager as suggested, I've tried to add a fetchRequestBlocks, see EDIT1 in my code above, but nothing changed.. – DAN Jan 25 '14 at 11:39
  • I'm assuming the entity name is correct. You don't really need a sort descriptor. Did you add a log / breakpoint to check it gets used? Are you logging context contents before, after and updated? What do all these logs show? – Wain Jan 25 '14 at 14:06