I'm building an app that heavily relies on CloudKit for data synchronization. Each time the app launches, it catches up with all changes that have been made on the server using a CKFetchNotificationChangesOperation. This successfully returns all objects that have been created and/or modified, but I am now at the stage that I also want my app to delete records based on these messages.
In my app, each object that I have stored in CoreData also carries the recordID of the online representation of that object. This way I can easily pick up objects I need to modify.
This seems hard when deleting objects, as CloudKit only returns recordID's for these objects, and does not provide a recordType that I can use to know what object I am looking for in my CoreData Database.
Question
How does one correctly handle CloudKit 'deleted' notifications in a case with multiple record types?
If CloudKit doesn't give you any indication of the type of record that was deleted, it's kind of a pain to deal with. You can't delete objects in Core Data without knowing the entity type, so if CloudKit doesn't give you any clues then you need to check every entity that could have the recordId.
The delete process is the same as usual with Core Data. Do a fetch request with a predicate of something like `recordId = %@" to find a matching object. If you find one, delete it. Except that you have to repeat this for each potential entity.
One approach that might help is to store the recordId in a new, separate entity. Create a new entity called something obvious like CKRecordInfo and keep the recordId there. Every other entity that has CloudKit info would have a one-to-one relationship to this entity. With this setup you'd fetch an instance of the new CKRecordInfo entity, and delete whichever object it's related to.
At the same time though-- I haven't used CloudKit, and it's more than a little surprising that it would give you just the recordId with no information about the record type. Getting the info from the notification would be ideal, if it's possible.