Implement sorting by rank achieved

[peppy]

[ticotaco72]

should be ranks fetched every time or saved/cached? if cached how long?

[frenzibyte]

should be ranks fetched every time or saved/cached? if cached how long?

probably saved to the database, wdym by how long? it should stay saved until a new rank is achieved

[ticotaco72]

how fast should cache expire, rank isn't constant

[peppy]

A first step would be importing the user's online score into the local database when importing or viewing the beatmap at song select.

[theabdulmateen]

+1, I really miss this feature

[Syndace]

Hi, I'd like to work on this. Or rather, I'd like to work on filtering by rank achieved first, since filtering, in contrast to grouping and sorting, isn't awkward with the current carousel UI/UX.

My first look at the problem yielded three main issues/topics for discussion:

1. Handling of online scores. This has been answered above by peppy already - we need to import online scores on specific events such as when importing a beatmap or when selecting one in the song select. I think this can nicely be decoupled from the initial implementation of filtering by rank achieved, by having the initial implementation only check local scores.
2. Efficient fetching of the best score from the database. There is TopLocalRank.cs, which subscribes to realm notifications for local score updates, sorts all scores by total score and takes the first. For filtering, however, a subscription seems overkill - I believe we only need a one-time fetch. This could be achieved by a subscription with an automated unsubscription on the first event, but I don't know if that's not a tad bit too hacky.
3. Filtering is currently sync while database access is async. Sync database access is likely not an option (am I right?), which means that the filtering would need to be rewritten to be async. Thoughts on that?

Do you see other major issues/topics for discussion around filtering by rank achieved?

(also I believe what we call "rank" here is called "grade" in lazer, right?)

[bdach]

For filtering, however, a subscription seems overkill - I believe we only need a one-time fetch.

I'm not so sure about that. What happens if you, say, import a score while the rank filter is active? That may impact the set of beatmaps that should be visible.

Filtering is currently sync while database access is async. Sync database access is likely not an option (am I right?), which means that the filtering would need to be rewritten to be async. Thoughts on that?

The bigger issue here is that the filtering should probably be done on the realm side fully before materialising objects, rather than after as done currently. That would help in this respect, but is a big undertaking that I would probably not recommend you try as a first contribution.

[Syndace]

What happens if you, say, import a score while the rank filter is active? That may impact the set of beatmaps that should be visible.

Right, nice.

The bigger issue here is that the filtering should probably be done on the realm side fully before materialising objects, rather than after as done currently.

I see, that's definitely the cleaner approach.

[...] but is a big undertaking that I would probably not recommend you try as a first contribution.

Right. The problem is that finding a good first contribution that is easier, sparks my interest and sets me up for more complicated topics isn't trivial either. I'll spend some time with the filtering/realm code and then report back once I have a better picture of the situation.

Thanks for your help/thoughts thus far!

[peppy]

Doing this for local plays should be first considered. Fetching online ranks is a completely different problem (and should at the end of the day only involve updated the local realm with this information, where it is not present or where the online rank is better than the already recorded local rank).

To make this efficient enough, the best rank is likely going to need to be normalised out against the beatmap, rather than checking against ScoreInfos. Either in BeatmapInfo directly, or in an EmbeddedObject attached to BeatmapInfo (like BeatmapUserSettings) if there's more than just the rank that we want to store in the future.

Getting it working locally may involve having a realm migration which populates this field at the point of migration from local scores.

[Syndace]

To make this efficient enough, the best rank is likely going to need to be normalised out against the beatmap, rather than checking against ScoreInfos.

The other approach I have in mind is making ScoreInfos sortable on realm-side. One way to potentially achieve that would be normalizing the TotalScore field, see #20299 . The advantage would be that it makes both fetching the top score/filtering on the top score possible, but also generally fetching scores in order, e.g. to show them in leaderboards.

What are your thoughts on that?