data_updater_v2.tables.changes
changes.py — the raw listing-event tables: every ticker rename, new listing and delisting
the vendors tell, as dated facts, with our ids where our catalog holds the security
(nc-feeds’ SymbolChange / ExchangeChange).
listings (symbol, date) a ticker starting to trade (FMP's IPO calendar, from ~2000, with its offering; Nasdaq's additions, from 2024)delistings (symbol, date) a ticker leaving (FMP's delisted list, from ~2022; Nasdaq's suspensions and deletions, from 2024)
symbol_changes (old_symbol, new_symbol, date) the rename on its first day under the new ticker; global_id, id (the new era's listing) and old_id (the era before's), reproduced from the security, the market and each tickerFMP tells the whole history (5,511 renames back to 1998, 2026-10-09), EODHD the renames from
2021-04-05 on; the DataClient combines them into one row per rename (in_fmp /
in_eodhd say who told it, disagree that their dates differ) before anything lands
here. The SEC is the fourth teller on every table (in_sec): a Form 25 for a delisting,
an 8-A for a listing, the ticker on the filer’s covers for a rename — asked over an
update’s window (its day route), never for the deep history, which FMP’s lists are. What no vendor tells, the universe update finds — a new era no listing explains, a
security’s identifiers under a new ticker, an era ended that no delisting or rename
explains — and gives back as rows for these tables
(in_universe), dated the update’s day. Raw rows are never rewritten to a new ticker: dbt reads these with the catalog’s eras
to carry a security across its tickers.
Classes
Delisting
Bases: Base
One ticker leaving a US venue, as told.
Listing
Bases: Base
One ticker starting to trade on a US venue (or expected to), as told.
SymbolChange
Bases: Base
One ticker rename on its effective day; the security keeps its global_id.