Because the detached store exists and has a chance to actually
semi-reliably intercept a beatmap update operation, I decided to try
this. It still uses a bit of a heuristic in that it checks for
transactions that delete and insert one beatmap each, but probably the
best effort thus far?
Notably old song select that was already doing the same thing locally to
itself got a bit broken by this, but with some tweaking that *looks* to
be more or less harmless I managed to get it unbroken. I'm not too
concerned about old song select, mind, mostly just want to keep it
*vaguely* working if I can help it.
While usually we'd handle this locally by moving bind operations to
`LoadComponent`, this component was explicitly made to be used in
asynchronous scenarios (to allow cases like song select to coexist with
realm without adding huge compliexities to the classes locally).
So I think it makes sense to hide this as an implementation detail. The
locked segments should all be quite fast to run so I do not see a
performance issue with lock contention here.
The intention here is to make things more testable going forward.
Specifically, to remove the "back-door" entrance into `BeatmapCarousel`
where `BeatmapSets` can be set by tests and bypas/block realm retrieval.
Bartłomiej Dach ·
Dean Herbert ·