CKReference.DeleteSelf attribute does not affect

Question

How does .DeleteSelf really work? The docs say:

When the action of the reference objects is set to CKReferenceActionDeleteSelf, the target of the link, that is, the record stored in the recordID file of the record, becomes the owner of the source record. Deleting the record of the target (owner) deletes all of its original records.

but my impression is that deleting the target will not always result in deleting the source. And this is pretty annoying when it stays in the container, the client loads it and expects the checkpoint to be somewhere, but the goal does not exist when creating a slice of the server data store on the client?

How do you feel about this business? Do you ignore such entries? Or do you periodically browse CloudKit storage looking for corrupted entries to delete them?

Or, instead of deleting a record, is it better to set an attribute that is in a remote state, but save it in the database?

Answer 1

I just struggled with this for a while, and I thought I would share my conclusions ...

This is basically a resolution problem. Cascading deletion will only work if the user deleting the records has write permissions for all the records that need to be deleted. Thus, in CloudKit Dashboard, cascading deletion will only work for entries created using the iCloud account of the developer.

If you need to delete records that do not belong to the user deleting them, you can add "write" permissions for the record type in the "Security" section.

Answer 2

If you remove the CloudKit Dashboard, you need to wait before switching record types to check the other end of the link. Most likely, you switched before the deletion really happened. You can use the Safari Web Inspector on the Network tab to check if the uninstall has finished. It takes a very long time to delete multiple entries.