Closed zwaldowski closed 12 years ago
If a developer treats deduplication as a potentially long-running, asynchronous background operation, then it might be wise to fire off a dedupe method in response to NSPersistentStoreDidImportUbiquitousContentChangesNotification
, and I'll add an AZCoreRecordDidFinishSeedingPersistentStoreNotification
notification to NSPersistentStoreCoordinator to accomplish the same thing. Maybe I'll link them together into AZCoreRecordManagerShouldDeduplicateNotification
, or something like that.
Apple recommends (by way of their WWDC 2012 Session 227 sample) to have a method to deduplicate entries in your Core Data store, likely caused by iCloud sync and seeding. Having duplicates is a good problem; you're not losing data! AZCoreRecord should send out notifications when it is appropriate to deduplicate, and should perhaps have helpers dedicated to finding duplicates based on attributes in the store, like how we import.
Apple deduplicates upon adding the iCloud store, but after seeding it with the contents of a fallback store. This is presumably the only place where duplicates not caused by the user can occur. However, their
-deDupe:
sample method accepts an NSNotification parameter, implying that there is something for it to hook into. Perhaps one of the Ubiquity-relatedNSPersistentStoreCoordinator
notifications would be a could place to shoot off our deduplication method, but it might be expensive to run such an operation in the background all the time.