In session wwdc20-10650 "Sync a Core Data store with the CloudKit public database" at 14:22, Nick says "NSPersistentCloudKitContainer can't use CKFetchRecordZoneChangesOperation with the public database, it has to use CKQueryOperation".
I was wondering why didn't you use CKSubscription? Create a subscription for each record type and the CKQueryNotification can contain CKQueryNotificationReasonRecordDeleted.
It's been a while since I worked on my own public database sync but I think that is how I did it.
This is the second time I've heard of the sync design being affected by limitations of CloudKit and it worries me. The first time it was when you decided not to use CKReference and instead create your own relation records because you said CloudKit had a limit on the number of references. Personally I didn't think the number was too low and I didn't understand why it couldn't just be raised, and if you had paired that with the non-public CKReferenceActionValidate it could have been a very solid solution. This year Nick came across as a bit unhappy with the current state of the sync, it was sad to see, compared to how enthusiastic he was last year especially getting to mention conflict-free replicated data type something he seemed really excited about. I really hope all of this can be resolved and the team can be happy again.
I was wondering why didn't you use CKSubscription? Create a subscription for each record type and the CKQueryNotification can contain CKQueryNotificationReasonRecordDeleted.
It's been a while since I worked on my own public database sync but I think that is how I did it.
This is the second time I've heard of the sync design being affected by limitations of CloudKit and it worries me. The first time it was when you decided not to use CKReference and instead create your own relation records because you said CloudKit had a limit on the number of references. Personally I didn't think the number was too low and I didn't understand why it couldn't just be raised, and if you had paired that with the non-public CKReferenceActionValidate it could have been a very solid solution. This year Nick came across as a bit unhappy with the current state of the sync, it was sad to see, compared to how enthusiastic he was last year especially getting to mention conflict-free replicated data type something he seemed really excited about. I really hope all of this can be resolved and the team can be happy again.
