The generation config collection and folders
Table of Contents
1. Summary
A market_data_generation_config is the named container that owns one or
more typed generation configs. It is declared in
ores.synthetic.api/domain/market_data_generation_config.hpp and it is the
top of the authoring tree. A folder row, declared in
ores.synthetic.api/domain/folder.hpp, is the place that container and its
feeds occupy in the hierarchy the Market Simulator browses.
2. Detail
2.1. The collection
The collection carries three things a reader has to hold apart.
- Its identity, which is a surrogate
idplus anamethat is unique in the system tenant. The system may hold several containers at once, for example a "Basic" set and a "Realistic" set, and the optionaldataset_idrecords which bundle dataset produced each one. A container made by hand has no dataset of origin, and that absence is how the two are told apart. - Its owner. Every collection belongs to the system tenant and the system party. See Generators belong to the system tenant and the system party.
- Its
enabledflag and a free-text description, and the usual audit block withmodified_by,performed_by, a change reason code and a change commentary.
2.2. The folder tree
folder is a generic self-referencing node. Its kind is one of "root",
"collection", "asset_class" or "instrument_type", and parent_id is
null for the root only. One root folder carries the name
"Simulator". A collection folder hangs under the root, the asset-class folder
hangs under the collection, and the instrument-type folder hangs under that.
A collection row is the only kind with collection_id populated. That
column points at the market_data_generation_config the row represents, and
the collection stays the source of truth for the name, the description, the
enabled flag and the dataset. The folder row keeps its own name in step so
the tree reads uniformly.
A feed finds its place in the tree through its own folder_id, which is
declared on fx_spot_generation_config and ir_curve_generation_config
alike.
2.3. The fact the code shape does not show
The tree is rows and never a parsed string. A generator's vendor instrument is
data on the config and never a path, so the hierarchy position and the id can
differ, and neither is derived from the other. The read path is
folder_repository::get_hierarchy, backed by
ores.utility/domain/hierarchy.hpp, so the shell and any future screen walk
the same function rather than each reimplementing a tree walk over
source_name.
folder_id is optional and only the bundle path fills it. An FX rate or a
curve made by hand in the editor has no folder until someone places it, so a
container can hold a generator the tree does not show.
3. See also
- Market Data Architecture — the structure note that orders this cluster, and where to read this page in it.
- Synthetic data generation screens, which draws the tree and the editors behind it.
- Generators belong to the system tenant and the system party — completes: who owns the collection.
- The FX spot generation config, the first kind of child.
- The IR curve generation config, the second kind of child.