ores.trading.scripted_instrument

1. Flags
2. Natural keys
3. Columns
4. Foreign keys
- 4.1. trade_id
- 4.2. trade_activity_id
5. Delete cascade
6. SQL
7. C++
8. See also

Represents the AMC script-based product types ORE states: ScriptedTrade with its inline or library script, Autocallable_01, DoubleDigitalOption and PerformanceOption_01. trade_type_code discriminates the exact product and script_name names the payoff script, while the optional JSON fields carry the script's events, its underlyings and its parameters. The table stays flat by design: it holds no nested sub-struct, because the script definition is embedded text and not a set of typed columns.

The table is a flat instrument sub-type, so it binds :profile: trading-instrument. Two table features justify that binding: the table is tenant-scoped through tenant_id and the tenant isolation policy, its insert trigger stamps party_id from the session variable app.current_party_id rather than taking it from the client. The profile also fixes the identity and audit field groups, the batch read and the generator facet, and leaves the table with no UI surface – the per-instrument forms were hand-crafted in the removed desktop client and consumed the generated messaging protocol.

1. Flags

2. Natural keys

3. Columns

3.1. trade_type_code

Trade type code (soft FK to ores_trading_trade_types_tbl).

Routes the ORE AMC scripted products: ScriptedTrade, Autocallable_01, DoubleDigitalOption and PerformanceOption_01.

std::string("ScriptedTrade")

3.2. party_id

Party that owns this instrument.

Set from session variable app.current_party_id.

3.3. trade_id

The trade this instrument belongs to, and the instrument's own key.

The trade id identifies both the trade and its instrument, so the instrument carries no identity of its own: this column is the key, and the trade it names gives the instrument its scope.

3.4. trade_activity_id

The activity that wrote this version.

3.5. script_name

Name of the ORE script that defines the payoff.

Names a library script, or the named product a scripted trade carries.

std::string("Autocallable")

3.6. script_body

Optional embedded ORE script body. Empty when the trade names a library script instead.

3.7. events_json

Optional JSON array of event schedule entries. Empty when not applicable.

3.8. underlyings_json

Optional JSON array of underlying asset codes. Empty when not applicable.

3.9. parameters_json

Optional JSON object of script parameters. Empty when not applicable.

3.10. description

Optional free-text description.

3.11. data_element

The element of the trade that states the parameters: ScriptedTradeData for a generic scripted trade, or the named product's element, such as MovingMaxYYIISData. The parameters are scripted_parameter rows, and the element tells the writer which of the two forms to state them in.

4. Foreign keys

4.1. trade_id

The trade that carries this instrument. An instrument is written beside its trade, so a row cannot exist without one.

#include "ores.trading.api/generators/trade_generator.hpp"
#include "ores.trading.core/repository/trade_repository.hpp"

{
    auto anchor = ores::trading::generators::generate_synthetic_trade(ctx);
    anchor.party_id = *party_ctx.party_id();
    ores::trading::repository::trade_repository().write(party_ctx, anchor);
    v.identity.trade_id = anchor.id;
}

4.2. trade_activity_id

The activity that wrote this version. A database foreign key: the activity is immutable.

#include "ores.trading.api/generators/trade_activity_generator.hpp"
#include "ores.trading.core/repository/trade_activity_repository.hpp"

{
    auto activity = ores::trading::generators::generate_synthetic_trade_activity(ctx);
    activity.party_id = *party_ctx.party_id();
    ores::trading::repository::trade_activity_repository().write(party_ctx, activity);
    v.identity.trade_activity_id = activity.id;
}

5. Delete cascade

The rows a scripted instrument owns: its parameters, their list values and the schedules its event parameters state. Each is keyed by the trade, so the delete rule closes them with the instrument.

5.1. scripted_parameters

5.2. scripted_parameter_values

5.3. instrument_schedules

5.4. instrument_schedule_dates

6. SQL

6.1. Flags

6.2. Checks

expression
"script_name" <> ''

6.3. Indexes

name	columns	unique	current_only	where_extra
party	tenant_id, party_id	false	true
trade_type	tenant_id, trade_type_code	false	true

7. C++

The C++ domain class is decomposed into nested sub-structs (the C1202 pattern from PRs #1047/#1071/#1075/#1083/#1085): the implicit scaffolding columns (version, tenant_id, the primary key) and the columns marked :group: identity above fold into an instrument_identity identity; member (see the ores.trading.instrument_identity field-group model), the implicit audit columns fold into an ores::dq::domain::audit_record audit; member (see the ores.dq.audit_record field-group model), and the remaining columns stay flat in between. The SQL schema, DB entity and column lists are unaffected – only the domain class and the mapper's domain-side accesses nest. The entity templates consume these annotations; domain and repository profiles regenerate correctly.

7.1. Flags

7.2. Repository

7.3. Domain includes

#include <string>

7.4. Conventions

7.5. Table display

column	header
identity.trade_id	ID
identity.trade_type_code	Type
script_name	Script
description	Description
audit.recorded_at	Recorded At

7.6. Custom repository methods

7.7. Write observation

The trade's economic digest observes every write of this component. The observer's specialisation must be visible where the repository writes, so the repository includes it.

#include "ores.trading.core/repository/trade_write_observation.hpp"

8. See also

ores.trading — component group overview.