Skip to main content

items_listing_sql

Function items_listing_sql 

Source
fn items_listing_sql(
    parent_is_library: bool,
    include_catalog: bool,
    type_filter: &str,
    favorites_filter: &str,
    order_by: &str,
    limit: usize,
    start_index: usize,
) -> String
Expand description

The listing query behind get_items: the cached children of one parent that are available to show.

An item is available when it is cached for browsing (synced_at, only while the catalog-browse flag is on — offline with the toggle off the page shows downloaded media only; see set_include_catalog_browse), when it is a playable item with a completed download, or when it is a container with a downloaded child. That is checked per row with EXISTS on the rows the parent selects. It used to be a CTE that materialised the id of every available item in the database (a UNION over the whole table) before filtering to the parent, which cost ~80 ms on a desktop for a 100k-item cache whatever the parent — several times that on a phone.

Children are matched on container_id, the logical container resolved by migration 027 (an episode’s season, a season’s series, a track’s album, otherwise the parent) — one index range, already in display order. It replaced a four-column OR that was both slow and wrong: every episode carries its series id, so a series listed its episodes beside its seasons. The library clause is added only when the parent is a library; inside the same OR it forces a scan of every row. The + on server_id keeps the planner off the server index, which every row shares.

Bind order: server id; the parent id (twice for a library parent); the type-filter values; with the favourites filter, the user id.

TRACES: UR-002, UR-007 | DR-013, DR-277