Other textual keyword filters also worked like that, wherein if you did
`artist=a artist=b` the second filter would overwrite the second, but in
those cases the query is against a single field, so attempting to put
multiple search criteria in conjunction on a single field is kind of
nonsensical, so it was sort of fine to do that.
Which is not the case for user tags, which are multi-valued.
The way that this works is that it plugs into the online request to
retrieve the beatmap set that the client is already performing, and
stores user tag data to the local realm database.
This means that for now user tags will only populate for beatmaps that
the user has displayed on song select which is obviously subpar. I plan
to follow this change up by adding user tag state dumps to `online.db`
and using that data for initial tag population to make the majority case
(ranked beatmaps) work.
Note that several decisions were made here that are potential discussion
points:
- `RealmPopulatingOnlineLookupSource` is set up such that it can be the
middle man / redirection point for similar flows that we need and we
are currently missing, such as storing guest difficulty information,
or storing the user's current best score on a beatmap (handy for rank
achieved sorting / filtering / etc.)
- The user tags are stored in `BeatmapMetadata` which breaks the
longstanding assumption that you can arbitrarily pull out a metadata
instance from any of the beatmaps in a set and get essentially the
same object back.
I've attempted to constrain this some by not adding user tags to
the `IBeatmapMetadataInfo` interface through which `BeatmapSetInfo`
exposes metadata further, but I warn in advance that this is
a temporary state of affairs and I will make it worse in the future
when `BeatmapMetadata.Author` becomes `Authors` plural in order to
support guest mapper display (and direct guest difficulty submission).
- The syntax for searching via user tags is chosen to mostly match web -
it's `tag=`, with support for all of the string matching modes song
select already has (bare word for substring, `""` quotes for phrase
isolated by whitespace, `""!` for exact full match).
The tests were relying on the `RulesetID` being set to 0 in the example
beatmap, even though the ruleset *instance* was set to ID 5.
This explicitly adds that 0 value to show intent, and also removes the
incorrect specification of 5 (which would cause the convert filter tests
to fail).
Also updates the filter code to use `OnlineID`, which is required in
realm changes.