jgt-pricedb

The persistence layer of the next-generation Price Service: bars live in a database with an incremental, anchor-based refresh — CSV files become an export, not the source of truth.

Lineage: implementation of the PDSP specifications reverse-engineered from the Caishen .NET stack — caishen/rispecs/PDSP/ (specs 70–77) — translated into the jgt ecosystem's shapes.

Structural Tension

• Current reality: price data as flat CSVs ($JGTPY_DATA/pds/<INSTR>_<TF>.csv); every refresh rewrites whole files and downstream recomputes whole series.
• Desired state: a database-backed store where refresh finds the anchor (the single forming bar per series) and writes only forward; downstream learns which bar changed and computes incrementally.

Decisions

• Portable schema (SQLite for local-first dev, PostgreSQL for deployment); the anchor invariant is enforced by a partial unique index (UNIQUE(series_id) WHERE is_forming), not by application discipline.
• No standalone importer. Backfill is the refresh engine's bootstrap path (PDSP spec 72, Algorithm C) fed by a source adapter. CsvSource reads the existing full/ CSVs through the exact same upsert path as BrokerSource live updates. The system can always rebuild itself from its own sources.
• CSV compatibility export (PDSP spec 75 pattern): consumers (jgtpy, jgtml, jgt-data-server) keep reading the same file paths while the database becomes authoritative underneath. Nothing breaks on day one.
• Redis pub/sub (already in the jgt-data-server stack) carries bar-completed events in Phase 4 — the role Rebus/MSMQ played in Caishen.
• pyproject.toml with a static version — deliberately avoiding the setup.py circular-import pattern that blocks other jgt packages from installing in containers.

Phases

Layout

• rispecs/ — jgt-native specifications (the buildable truth; start here)
• src/jgtpricedb/ — the library
• docker-compose.yml — optional Postgres for deployment; SQLite needs nothing