This helps slightly with performance, allows better monitoring via realm
studio, but most importantly greatly reduces filesize.
fully compacted: 109M
transaction size 100: 115M
transaction size 1000: 123M
transaction size 10000: 164M
single transaction: 183M
With a transaction size of 100 there is a performance reduction, so 1000
seems to be the best middle-ground.
This really shouldn't have much effect as it will be run in the first
`Update` method and is probably a noop (we are already pointing to the
newest version due to just performing writes), but seems like a safe addition.
In general `Realm.Refresh()` only really does anything when there's multithreaded
usage and notifications to be sent.
It seems that no usages of `BeatmapSetInfo` detaches require files - a
`WorkingBeatmap` is always obtained before doing further lookups.
Therefore we can omit this include unless the detaching object is a
`BeatmapInfo`. A refetch is performed when retrieving a
`WorkingBeatmap` to complete the equation.
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.
The reason this was happening was an unfortunate oversight in the
migration logic. The code that was attempting to parse the skin settings
as `int` was firing regardless of whether a skin migration from EF to
realm had already occurred. If it had occurred, the skin setting would
contain a GUID rather than an integer, and therefore fail to parse, and
therefore implicitly fallback to a EF skin ID of 0 which would be the
default skin.
Fix by not running the setting migrating logic at all when there are no
EF skins to migrate.
