Route all delete methods in Realm.swift through RLMRealm

[TimOliver]

Hey @tgoyne! Long time no see! Thanks so much for continuing to maintain the community branch of Realm!

I have a quick PR here. My use-case for it might be a little hacky, so if you know of a better way, I'm happy to amend this as needed.

For my use-case, I'm looking at building a third-party library to enable syncing data between Realm and CloudKit. Ideally, in a way where the developer just interacts with the Realm APIs as normal and the syncing mechanism occurs completely seamlessly in the background.

I can dynamically subscribe to Realm changes in order to receive fine-grained notifications when the user adds or modifies Realm objects, however this approach doesn't work when the user deletes an object. By the time the fine-grained notifications fire, the object is already deleted, so there's no way for me to capture its PK in order to forward that to CloudKit.

My idea here is to use swizzling to hook all of the Objective-C [RLMRealm delete] methods and use that to capture all of the objects just in time before they are deleted. In order to do this though, all of the Realm Swift APIs that are talking to the Object Store directly need to be modified so they go via RLMRealm instead.

Maybe not the most elegant solution on my behalf. I would imagine adding a willDelete event to the fine-grained notifications would be the most appropriate solution here. But I'm hoping this is the most superficial modification necessary to let me achieve the same outcome, with a negligible performance impact for everyone else. And, it also makes all of the delete methods go via RLMRealm, which is hopefully more consistent to boot.

Finally, I'm still very invested in Realm's future. If there's anything I can do to help support the community branch, please let me know. Thanks again so much!

[cla-bot]

Realm welcomes all contributions! The only requirement we have is that, like many other projects, we need to have a Contributor License Agreement (CLA) in place before we can accept any external code. Our own CLA is a modified version of the Apache Software Foundation’s CLA. Our records show that CLA has not been signed by @TimOliver. Please submit your CLA electronically using our Google form so we can accept your submissions. After signing the CLA you can recheck this PR with a @cla-bot check comment. The GitHub usernames you file there will need to match that of your Pull Requests. If you have any questions or cannot file the CLA electronically, make a comment here and we will be happy to help you out.

[TimOliver]

@cla-bot check Signed the CLA!

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[tgoyne]

I don't remember offhand why deleteAll doesn't go through RLMRealm in the first place. I'm pretty sure it was just for symmetry and there's no obvious reason why it couldn't...

It's sort of annoying that we never figured out what to do API-wise to expose the PK of deleted objects. All of the complicated logic to be able to capture them is there and it's just not surfaced.

[TimOliver]

I was wondering that too. Especially when half of the delete methods go through RLMRealm and the other half don't. I assumed if you can tap directly into the Object Store, you're still saving some performance by removing one level of abstraction (even though the perf gains might be negligible).

Yeah? I always wondered if it straight up wasn't possible due to the ordering of events. Being able to surface it through an official interface rather than the hacky way I'm proposing here would be great.

[tgoyne]

ObjectChangeCallbackWrapper records the old values of the properties in the before change callback, and then just doesn't pass them to the registered block. I don't think there's any good reason for it to not be surfaced as .delete(_ changes: [PropertyChange]) other than single object observers being a bit half-baked.

For collections CollectionCallbackWrapper would need to be switched to having before/after functions, gather information in before(), and then somehow pass it on to the caller in after().

[TimOliver]

Thanks so much for merging Thomas!

Hmmm I see. I certainly feel like getting to see the full context of what the user changed would be amazing. Not just for my use-case, but certainly in general. If I get some more free time, I'll see if I can look into it myself at some point.

Thanks again! All the best, and do please let me know if there's anything I can do to help out here again! :)