The most common scenario is switching between schema versions when
testing. This should alleviate the manual overhead of that for the
majority of cases.
For users, this will show a notification on startup if their database
was purged, similar to what we had with EF.
I can't confirm this works yet, since I'm not sure what the
preconditions are for the `.note` file to be created. What I can confirm
is that a `.note` file hasn't appeared in my game data directory yet.
I've updated all cases where we should have been using
`GetDisplayString()` anyway, but left the `ToString()` implementations
in place for safety. They should probably be removed in the future.
This may not be the cleanest solution, but there don't seem to be any
way towards this either.
- `UseDestinationValue` has been inherited by default as noted in
https://docs.automapper.org/en/stable/10.0-Upgrade-Guide.html#usedestinationvalue-is-now-inherited-by-default, and its behaviour in this case would be using the nested **managed** realm object for the destination member rather than creating an unmanaged version.
- `MaxDepth` already sets `PreserveReferences` so there's no point of using it.
- `MaxDepth` should probably not be set for all maps, only for those with
cyclic references, to avoid the expensive overhead of `PreserveReferences`, as mentioned in https://docs.automapper.org/en/stable/5.0-Upgrade-Guide.html#circular-references.
That aside, `MaxDepth` should actually only be set to `1` for
`BeatmapSetInfo` mapping, because we don't want AutoMapper to create a
nested instance of `BeatmapSetInfo` in each mapped/detached beatmap, but
for some reason, doing that will cause automapper to not map any beatmap
inside the set and leave it with 0 beatmaps.
While on the other hand, using `MaxDepth(2)` for `BeatmapSetInfo` works,
but creates an unused instance of a `BeatmapSetInfo` inside each mapped
beatmap, which may not be ideal.
For `BeatmapInfo`, it has to be `MaxDepth(2)`, in which the first
`BeatmapInfo` depth would be itself (when detaching a beatmap), and the
second would be nested beatmaps inside the mapped/detached
`BeatmapSetInfo` within the beatmap. (note that when detaching a beatmap
set, the unused instance of `BeatmapSetInfo` within each beatmap of that
beatmap set doesn't also have a list of unused beatmaps as one might expect from the depth specification, it surprisingly has 0 beatmaps)
This causes it to create an unused instance of `BeatmapInfo` in the beatmap set resembling the root mapped/detached beatmap, but that one might be inevitable.
The task not being cleared in the early return path would cause
`pendingRequestTask` to become stuck as a completed task, and
`queryValue()` would not recreate it due to the null check there,
therefore stalling all lookups forevermore until a game restart.
