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

The name registry is the database layer's string table for game identity fields. Player, event, site and round names are stored once in NameBase; metadata rows keep compact idNumberT handles into the appropriate nameT bucket. This keeps the index small while still letting callers resolve human-readable names when they need them.

TagRoster is the narrow bridge between database IDs and PGN's Seven Tag Roster names. When loading or exporting a game, tagRoster() resolves an IndexEntry through the current NameBase and returns borrowed string pointers. When saving, TagRoster::map() maps those strings back to IDs, adding names when the storage backend allows it.

A name ID is not globally meaningful. It is meaningful only together with its bucket: player ID 7, event ID 7 and round ID 7 point into different NameBase tables. Public value snapshots such as GameInfo preserve that compact form, so callers that want strings either call tagRoster() for one game or read the registry through getNameBase().

The registry owns the returned strings. Pointers from GetName() and TagRoster remain borrowed views into the current database namebase; they are not independent strings and should not be kept past the lifetime of the database state that produced them.

Domain Model

This diagram shows the public string/ID boundary. It leaves storage-codec details loose: SCID4 and SCID5 persist names differently, but the in-memory contract is the same once the database is open.

NameBase owns the four name buckets and their legacy-compatible lookup order. IndexEntry and GameInfo store IDs. TagRoster exposes borrowed strings for Event, Site, Round, White and Black. getNameFreq() is a derived view: it asks the registry to scan the current index and count how often each name ID is referenced.