libscid snapshot+b450b7969924
Chess applications made easy.
Source on GitHub License GPL v2
Loading...
Searching...
No Matches
Database

Database is the persistence and query layer above Core. It stores chess games in database formats, keeps searchable metadata resident in memory, resolves stored name identifiers, and materialises editable scid::core::Game values when callers need full game content.


scidBaseT is the session facade. It owns the open database state, coordinates codecs, filters, sort caches and metadata, and is the usual public entry point for database work.


Database metadata is the resident catalog behind browsing, filtering, sorting and metadata-only updates. It lets callers answer many database questions without decoding a complete Game.


Name registry owns the canonical player, event, site and round strings. Metadata stores compact name IDs; callers resolve those IDs through the registry when they need display text or PGN roster tags.


Filters and views define which games are visible to list, search, tree and bulk-update workflows. Filters are stored as per-game byte values rather than plain booleans, so a visible game can also carry a ply hint used by position and tree features.


Tree turns a position-search filter into opening-style move statistics. It groups the next move played by each visible game and reports count, score, rating and year aggregates for each candidate.


Storage codecs map the resident database session to concrete files or in-memory storage. They persist the index entries, name registry and encoded game records while the public session API continues to exchange Core game values and metadata snapshots.


Full game content is loaded on demand. Listing, sorting, filtering, flag updates, many metadata edits, and search prefilters can work from metadata alone. Loading or saving a complete game crosses into Core: the codec decodes stored bytes into scid::core::Game, or encodes a Game back into the active database format.