Filters and views are the database layer's way to look at a subset of the metadata catalog without loading complete games. A filter answers "which games are visible?" and can also carry a small per-game value. A view takes that filtered set and presents it in a stable order for UI pages, search results, tree statistics or bulk operations.

Filter is the dense storage: one byte per game, with zero meaning excluded and non-zero meaning included. HFilter is the public handle most APIs accept. It can view a main filter by itself or the intersection of a main filter and a read-only mask. HFilterInverted is the complementary range used by OR-style searches that only need games not already included.

The stored filter value is deliberately not just a boolean. A value of zero excludes the game. A value of one includes the game at the start-position hint. Larger values encode ply + 1, so a position search can remember where the match occurred and a tree view can reopen the game at the relevant point. When the filter is all included at value one, Filter uses a lazy representation and does not allocate the byte array.

Domain Model

This diagram expands filters and list views into the public types programmers meet. It is intentionally loose: it shows how filter handles, filter storage and sorted result pages relate, without exposing the private sort-cache implementation.

scidBaseT owns the default filter and named filters. newFilter() creates a named filter, getFilter() resolves IDs such as dbfilter, all, and IDs returned by newFilter(), and composeFilter() creates an intersection ID of the form +main+mask.

HFilter is pointer-like because many call sites treat it as a nullable handle. Iterating *filter yields included game numbers through HFilter::const_iterator; get() returns the visible byte value. Mutating operations update only the main filter, even when a mask is present.

Sorted views are produced by listGames() and sortedPosition(). They combine an HFilter with the resident metadata catalog and a compact sort criterion string. Retained sort caches make repeated paging cheap, but callers still see only game numbers suitable for gameInfo(), tagRoster() or loadGame().