Genres and MusicGenres both answer with every genre #52
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
/Genresand/MusicGenresboth answer with every genre in the library.Over a production library:
/Genres/MusicGenresUpstream keeps the two apart — a film's genres and a track's are different
items, and only ten names appear in both. This server answers each route with
what looks like the union of the pair, so
/Genresleads with52,AcidandAcid Techno, and/MusicGenresoffersAction & AdventureandAnime.A client showing genre filters on a movie library is offered music genres that
match nothing there, and the other way round.
The reference library's genres barely overlap the two kinds, which is why
answering both from one list has passed so far.
Both issues were one cause, and it was not the scanner: both servers read copies
of the same upstream-written database, so how a name is split never came into it.
The by-name listings walked
ItemValuesand grouped byCleanValue. Upstreamqueries
BaseItems(BaseItemRepository.ByName.cs,GetItemValues): rows ofthe item type the route names, one per
PresentationUniqueKey, whoseCleanNamematches a value of the given type in reach.GenreandMusicGenrearedifferent rows over the same values, and
GenresControllerswitches to themusic kind when the parent is a music library. Neither was done here.
Fall Out Boy/Fall Out BoyandScooter & Harris & Ford/Scooter, Harris & Fordare two rows each sharing one folded name. Groupingby clean value collapsed each pair; upstream lists both.
Measured over one production database, both servers, identical ordering as well
as counts:
/Genres/MusicGenres/Artists/AlbumArtists/Artists/Studios/Items/Filters2picks the genre kind the same way and reads the same listing.Two things worth recording. Upstream answers these from rows alone and returns
nothing where a scan never created them; this server's scan writes no
Genre/MusicGenre/Studiorows at all, so the derive-from-values fallback iskept for names no row stands for, now under upstream's own owner-type rule. On
any database upstream scanned the fallback adds nothing — measured, zero orphan
values across all five listings. That this port's scan has no validator
equivalent is a real gap, and is filed separately.
MILESTONES.mdsays a by-name item is never a row here, which is no longertrue.