vike
ConceptsData

chain

The chain store kind: its columns, partitioning, what venue and symbol mean for it, and the producers that write it.

chain is one of the shapes the historical store holds. A stored series lives under a kind= path segment, and that segment is the layout contract its producers and its consumers have to agree on: the columns, how the leaf is partitioned, and what venue and symbol mean for this particular kind. All of it is below, rendered from the same table the runtime dispatches on.

One decoded row becomes a crate::chain_log::ChainRow. The codec that owns the schema is ChainCodec; the store writes through append_chain_snapshot and reads through scan_chain, and parts carry the Parquet metadata key vike.schema.chain.

Identity

venue = the options venue; symbol = the UNDERLYING (and underlying is ALSO a row column). All rows of one snapshot share ts, so this kind is the only one where a single timestamp legitimately covers hundreds of rows

This is the field most often assumed and most often wrong, which is why it is stated per kind rather than once for the store.

Columns

Every Arrow column today's writer emits, in schema order, with the codec flavor that picks its Arrow type and nullability.

ColumnFlavorNote
tsi64—
underlyingstr—
instrumentstr—
expiry_msi64—
strikef64—
is_callbool—
bidf64_nullalways PRESENT, and may hold SQL NULL
askf64_nullalways PRESENT, and may hold SQL NULL
markf64_nullalways PRESENT, and may hold SQL NULL
ivf64_nullalways PRESENT, and may hold SQL NULL
open_interestf64_nullalways PRESENT, and may hold SQL NULL
volumef64_nullalways PRESENT, and may hold SQL NULL
deltaf64_nullalways PRESENT, and may hold SQL NULL
gammaf64_nullalways PRESENT, and may hold SQL NULL
thetaf64_nullalways PRESENT, and may hold SQL NULL
vegaf64_nullalways PRESENT, and may hold SQL NULL

Layout

PropertyValue
Partitioningsymbol
Grouped formno — one series per part
In the cross-kind tick reportno

Traps

⚠ Volume warning, not a contradiction: at the recorder's default cadence one underlying is hundreds of rows per minute, so the unbounded point-in-time read crate::HistStore's chain_as_of decodes every row ever recorded on each call. chain_as_of_within is the bounded twin and is what a backtest should use.

Pinned rather than fixed: the contradiction is recorded with both sides named, so a reader meets it here instead of in production.

Known producers

Idempotency in this store is batch-level and keyed on a commit-key string, never on per-row value dedup. Two producers that collide on one template silently no-op each other's appends, and a producer that changes its template re-admits history it already wrote — both invisible unless the shapes are written side by side.

ProducerCommit-key template
crates/vike-data/src/chain_rec.rschain:{venue}:{underlying}:{expiry}:{bucket}

⚠ That list is observed, not exhaustive, and no gate can make it so: a commit key is an ordinary string argument, so proving the list complete would mean following every call in the workspace. What is gated per listed entry is that the producer exists and spells the template verbatim. Read it as "these producers write this kind", never as "only these do".

Where this comes from

vike_data::store_kind::STORE_KINDS, exported as rosters.json at every release. The store's own gate derives the live kind set from the code — the series directory literals, the compaction dispatch and the write verbs — and fails until a new kind has a row, so this page cannot describe a shape the store does not write.

On this page