Saving managed objects in different CoreData contexts doesn't sync to Dropbox

[vijayj]

Our app has a default context where most of the work is done, and a different context for creating and editing entities. Our PKSyncManager points to the default context. We synchronize between the contexts using NSManagedObjectContextDidSaveNotification and mergeChangesFromContextDidSaveNotification. When changes are merged into the default context they aren't synced to Dropbox because PKSyncManager only listens for NSManagedObjectContextWillSaveNotification on its context, which doesn't happen on our default context when merging changes.

We have a potential fix vijayj#1 with a couple issues:

1. It requires the client code to call a new method managedObjectContextDidSave: when the default context merges changes.
2. This new method managedObjectContextDidSave is getting called when updateCoreDataWithDatastoreChanges: saves changes from Dropbox, leading to inefficiency.

Our fork also fixes an issue where syncIDs are not set across related objects soon enough.

[vijayj]

Another issue we found with our approach is that the syncID isn't getting set for entities being created on the background context. This then leads to duplicate records in CoreData, one with a syncID and one without. We don't have time to fix this now, so we changed our project to create entities in our default context. It would still be nice to have this issue resolved at some point. Thanks.

[lyahdav]

We have a new fix for this issue vijayj@a72feeb but we can't make a pull request for that single commit. Can you take a look at that commit and merge if it makes sense? The fix was to observe changes at the persistent store coordinator level instead of the managed object context level. If you have a better suggestion please let us know. Thanks.

[daikini]

I think I may have a solution for handling your issue. In a test branch (https://github.com/overcommitted/ParcelKit/tree/observe-multiple-contexts) I've added the ability to add additional managed object contexts to listen for changes from.

The two new instance methods on PKSyncManager are addObserverForManagedObjectContext and removeObserverForManagedObjectContext.

This should allow you to add and remove managed object contexts for listening to changes.

Will this solution work for your needs?

[lyahdav]

In theory this looks like it'll work. We'll test it next week and get back to you. Thanks!

[daikini]

@vijayj, @lyahdav Have you been able to test this and see if it works for you? I'm preparing for a new ParcelKit release and would like to get it in there if it does.

Thanks!

[vijayj]

@daikini - Jonathan, we are sorry but we did not get a chance yet to test the new branch. We have a story for it that we plan to ideally execute next week. Please let us know when you plan to do a new release.

[daikini]

I'll go ahead and do a release when you've had a chance to test and verify that it works for your use case.

[vijayj]

@daikini - We are actually looking at using this branch today. However, while it is easy for us to decide when to call addObserverForManagedObjectContext, we are having a bit of challenge on when to call removeObserverForManagedObjectContext. We use ARC for deallocating the contexts so ideally we want to call remove when the context is deallocated. This is hard because PKSyncManager holds a strong reference to the context.

One solution would be to hold weak references to context similar to this post here - http://stackoverflow.com/questions/9336288/nsarray-of-weak-references-to-objects-under-arc

What would be your suggestion for this issue ?