Falls into the age-old trap of attempting to retrieve an item from realm
without first ensuring that realm is in an up-to-date state.
Consider this scenario:
- Editor is entered from main menu, causing it to create a new beatmap
from its async `load()` method.
- Editor opens correctly, then main thread performs a file operations on
the same beatmap.
- Main thread is potentially not refreshed yet, and will result in `null`
instance when performing the re-fetch in `performFileOperation`.
I've fixed this by using the safe implementation inside `RealmLive<T>`.
Feels like we want this is one place which is always used as the correct
method.
On a quick search, there are 10-20 other usages of `Realm.Find<T>` which
could also have similar issues, but it'll be a bit of a pain to go
through and fix each of these. In 99.9% of cases, the accesses are on
instances which couldn't have just been created (or the usage of
recently-imported/created is blocked by realm subscription flows, ie.
baetmap import) so I'm not touching them for now.
Something to keep in mind when working with realm going forward though.
The code here was assuming that if the beatmap which is having changes
copied across does not exist within the `BeatmapSet.Beatmaps` list, it
was not yet persisted to realm.
In some edge case, it can happen that the beatmap *is* persisted to
realm but not correctly attached to the beatmap set. I don't yet know
how this occurs, but it has caused loss of data for at least two users.
The fix here is to check realm-wide for the beatmap (using its primary
key) rather than only in the list. We then handle the scenario where the
beatmap needs to be reattached to the set as a seprate step.
---
This does raise others questions like "are we even structuring this
correctly? couldn't a single beatmap exist in two different sets?"
Maybe, but let's deal with that if/when it comes up.
