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 id plus a name that 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 optional dataset_id records 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 enabled flag and a free-text description, and the usual audit block with modified_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

Emacs 29.3 (Org mode 9.6.15)