RestKit: a managed object displayed inside a simple old Objective-C object

Question

Preamble: I am using RestKit 0.21.0, but I also tried 0.23.0.

I have several mappings in which the plain old Objective-C object (let it call POOCO) contains NSManagedObject . It appears that when executing GET requests on this root POOCO, the managed entity is created under mainQueueManagedObjectContext .

However, when I do PUT against POOCO, when the response is loaded (the response is a copy of the sent object), a managed sub-object is created under the temporary NSManagedObjectContext , the parent of which is mainQueueManagedObjectContext .

Quick switch to re-fetch in RestKit:

If the request consisted entirely of NSManagedObject instances, the resulting objects would be “returned” using (I think) mainQueueManagedObjectContext . (IIRC, once all object matching has been completed, the objects and sub-objects will be re-mapped from the main MOC, replacing the objects created on the temporary MOC used for matching.)

This repetition is performed (as far as I can tell), because when the MOC receives dealloc , all the managed objects it manages become invalid . Thus, we return the objects to the MOC to which myObjectManager.managedObjectStore maintains a strong reference so that they remained valid after the interim MOC leaves.

Since the root object in the mapping is POOCO, any links that it has to managed objects are not re-received, so they remain attached to the temporary MOC and become invalid after the mapping is completed.

Does anyone else encounter such problems? Are there any recommendations you can offer? Can I tell RestKit, "restore these managed objects using mainQueueManagedObjectContext " or something like that?

Answer 1

In fact, the question has some misconceptions about when RestKit is redialing. Under the conditions described in the question, RestKit actually returns an instance of RKRefetchingMappingResult in a success block. Calling any of the accessories on this object (for example, array or firstObject ) really does reselect. The error was that I never called any of these methods on RKMappingResult .

My assumption was that since the object that I sent in the PUT request became the targetObject operation, the object would be updated in place of RestKit. That is why I never felt the need to do anything with RKMappingResult . The assumption is not technically wrong, but by accessing the object immediately after the mapping was completed, and not using RKMappingResult , I skipped the redial step.

I suggested changing this behavior in issue , which I filed with RestKit people in order to automatically re-configure certain circumstances.

Summarizing:

When querying using RKManagedObjectRequestOperation (whether you specify it manually or RestKit selects this class for you), always make sure that you run RKMappingResult to ensure that the results are re-fetched from the correct NSManagedObjectContext .

Answer 2

Managed instances of objects cannot be transferred between threads, and RestKit performs matching against background threads. If the returned objects are managed objects, they will be transferred to the main thread for you. It can be argued that nested managed objects that are not switched to the main thread for you are an error / supervision in RestKit (which you could raise as a problem in github).

You can ask RestKit to use the main thread for some things (explicitly creating operations and starting them, although this does not cover everything), but you really do not want to do this.

So, your main option is to have a method in your container object, which you can call in the success block and which iterates through the contained managed objects and "repeats" them - as you know, all objects exist can be executed using objectWithID: and the success block is called in the main thread.