Yeah, that sounds like a fair strategy, except that lots of nice things using KVO are now really hard because if you go online/offline you would be switching between different NSManagedObjects in different contexts. (In practice, we rarely use NSFetchRequests because our usage patterns fit well into the object graph, thus we use lots of KVO).
The two solutions would be A) make a NSManagedObject proxy class that actually proxies between the two NSManagedObject instances in different contexts (and maybe handle the replication here as well), or B) use two different NSPersistantStores in one context - but I cannot, for the life of me figure out how CoreData resolves conflicts between different Stores (network and sqlite) in the same Coordinator (NSMergeConflict doesn't seem to discuss this case).
Does anyone have experience using multiple stores and actually understand how NSPersistentStoreCoordinator handles conflicts?
Comments
Yeah, that sounds like a fair strategy, except that lots of nice things using KVO are now really hard because if you go online/offline you would be switching between different NSManagedObjects in different contexts. (In practice, we rarely use NSFetchRequests because our usage patterns fit well into the object graph, thus we use lots of KVO).
The two solutions would be A) make a NSManagedObject proxy class that actually proxies between the two NSManagedObject instances in different contexts (and maybe handle the replication here as well), or B) use two different NSPersistantStores in one context - but I cannot, for the life of me figure out how CoreData resolves conflicts between different Stores (network and sqlite) in the same Coordinator (NSMergeConflict doesn't seem to discuss this case).
Does anyone have experience using multiple stores and actually understand how NSPersistentStoreCoordinator handles conflicts?