-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Saving managed objects in different CoreData contexts doesn't sync to Dropbox #22
Comments
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. |
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. |
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 This should allow you to add and remove managed object contexts for listening to changes. Will this solution work for your needs? |
In theory this looks like it'll work. We'll test it next week and get back to you. Thanks! |
@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. |
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. |
@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 ? |
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
andmergeChangesFromContextDidSaveNotification
. 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:
managedObjectContextDidSave:
when the default context merges changes.managedObjectContextDidSave
is getting called whenupdateCoreDataWithDatastoreChanges:
saves changes from Dropbox, leading to inefficiency.Our fork also fixes an issue where syncIDs are not set across related objects soon enough.
The text was updated successfully, but these errors were encountered: