ORE Import / Export Code Cleanup

New file: ores.trading.api/include/ores.trading.api/domain/instrument.hpp

namespace ores::trading::domain {

/**
 * @brief Satisfied by every concrete per-type instrument struct.
 *
 * Requires value-type semantics and the two cross-cutting UUID fields
 * that all instruments carry regardless of family.
 */
template<typename T>
concept Instrument = std::regular<T> && requires(T t) {
    { t.instrument_id } -> std::convertible_to<boost::uuids::uuid>;
    { t.trade_id }      -> std::convertible_to<boost::uuids::uuid>;
};

} // namespace

Verify that every existing concrete instrument struct (fx_forward_instrument, vanilla_swap_instrument, bond_instrument, etc.) satisfies the concept with static_assert. Any that do not must have instrument_id and trade_id fields added (see also Phase 5).

In the same header or a sibling instrument_legs.hpp:

/**
 * @brief Pairs an instrument with its associated leg collection.
 *
 * Used for swap (rates) and composite families, which carry structured
 * sub-rows alongside the primary instrument record.
 */
template<typename T, typename Leg>
struct with_legs {
    T instrument;
    std::vector<Leg> legs;
};

using swap_instrument_data      = with_legs<rates_instrument_variant, swap_leg>;
using composite_instrument_data = with_legs<composite_instrument, composite_leg>;

Generic UUID stamping using the concept:

template<Instrument T>
void stamp_ids(T& instr,
               boost::uuids::uuid instrument_id,
               boost::uuids::uuid trade_id) {
    instr.instrument_id = instrument_id;
    instr.trade_id      = trade_id;
}

template<Instrument T, typename Leg>
void stamp_ids(with_legs<T, Leg>& data,
               boost::uuids::uuid instrument_id,
               boost::uuids::uuid trade_id) {
    stamp_ids(data.instrument, instrument_id, trade_id);
    for (auto& leg : data.legs)
        leg.instrument_id = instrument_id;
}

For inner-variant families (FX, equity, rates) where the instrument field is itself a variant, stamp_ids requires an overload that dispatches with a concept-constrained lambda:

template<typename... Ts>
    requires (Instrument<Ts> && ...)
void stamp_ids(std::variant<Ts...>& v,
               boost::uuids::uuid instrument_id,
               boost::uuids::uuid trade_id) {
    std::visit([&]<Instrument I>(I& instr) {
        stamp_ids(instr, instrument_id, trade_id);
    }, v);
}

New file: ores.trading.api/include/ores.trading.api/domain/trade_instrument.hpp

namespace ores::trading::domain {

/**
 * @brief Unified instrument carrier used in both import and export paths.
 *
 * std::monostate — trade has no instrument (unsupported type or new trade).
 * All other alternatives are mutually exclusive; exactly one is active.
 *
 * Families with associated leg collections (swap, composite) use
 * with_legs<> wrappers. Families with multiple sub-types (FX, equity,
 * rates) use their existing inner variant. Single-type families carry
 * the domain struct directly.
 */
using trade_instrument = std::variant<
    std::monostate,
    swap_instrument_data,            // rates family: instrument + legs
    fx_instrument_variant,           // FX family: 7 sub-types
    bond_instrument,                 // bond
    credit_instrument,               // credit
    equity_instrument_variant,       // equity family: 9 sub-types
    commodity_instrument,            // commodity
    composite_instrument_data,       // composite: instrument + legs
    scripted_instrument              // scripted
>;

} // namespace

stamp_ids for the full carrier dispatches to the overloads above:

void stamp_ids(trade_instrument& ti,
               boost::uuids::uuid instrument_id,
               boost::uuids::uuid trade_id) {
    std::visit([&]<typename T>(T& v) {
        if constexpr (!std::is_same_v<T, std::monostate>)
            stamp_ids(v, instrument_id, trade_id);
    }, ti);
}

In importer.hpp, change trade_import_item.instrument from domain::instrument_mapping_result to trading::domain::trade_instrument.

In trade_protocol.hpp, change trade_export_item.instrument from trading::messaging::instrument_export_result to trading::domain::trade_instrument.

Both types now carry the same trade_instrument field — no bridge required anywhere.

In each *_instrument_mapper.hpp, change the return type of every forward_* method from *_mapping_result to the corresponding trade_instrument alternative directly (or construct a trade_instrument at the call site in trade_mapper). Delete all *_mapping_result structs.

In trade_mapper.hpp, instrument_mapping_result becomes:

using instrument_mapping_result = trading::domain::trade_instrument;

Or remove the alias entirely and use trade_instrument directly.

Delete:

• All *_mapping_result structs from ores.ore::domain.
• All *_export_result structs from ores.trading.api::messaging (instrument_protocol.hpp) along with instrument_export_result.

Update all includes. The compiler enforces completeness.

The composite_instrument_data wrapper (from Phase 1) already provides the legs field. The mapper must now populate it.

In composite_instrument_mapper.cpp, after reading composite_instrument fields, read <Components> from the XSD and populate result.legs with composite_leg records. Mirror the pattern in swap_instrument_mapper which reads legs into swap_instrument_data.legs.

The composite branch in import_portfolio_with_context stamps result.instrument.id today. After Phase 1 it uses the generic stamp_ids overload which handles both instrument and legs uniformly — no bespoke branch needed.

Add or extend existing composite roundtrip tests to assert that legs are populated after a forward mapping.

Remove boost::uuids::random_generator gen and all UUID / product_type assignment lines from the std::visit block. Returned trade_import_item objects carry nil UUIDs.

product_type stamping: verify whether any downstream caller reads product_type before the planner mints IDs. If so, keep just that stamp and document the dependency. Otherwise remove it too.

ore_import_planner::plan() already generates trade.id and calls the now-deleted helpers. Replace with direct use of stamp_ids:

item.trade.id = uuid_gen();
const auto instr_id = uuid_gen();
stamp_ids(item.instrument, instr_id, item.trade.id);
item.trade.instrument_id = instr_id;

The generic stamp_ids (Phase 1) handles all families uniformly with no per-family branching in the planner.

No callers remain. Delete from importer.hpp and importer.cpp.

Delete importer::import_portfolio(path) and update its test to use import_portfolio_with_context instead.

template<typename S, typename T>
concept InstrumentService =
    Instrument<T> &&
    requires(S s, const std::vector<std::string>& ids) {
        { s.get_instruments(ids) } -> std::same_as<std::vector<T>>;
    };

All per-type services will satisfy this concept after 4b.

Each per-type service gains:

std::vector<instrument_type> get_instruments(
    const std::vector<std::string>& ids);

SQL pattern (same for all):

SELECT * FROM ores_trading_<type>_instruments_tbl
WHERE instrument_id = ANY($1::uuid[])

Services requiring batch leg fetch (fra_instrument_service, composite_instrument_service) additionally gain:

std::map<std::string, std::vector<leg_type>>
get_legs_for_instruments(const std::vector<std::string>& ids);

SQL: WHERE instrument_id = ANY($1::uuid[]); results grouped by instrument_id in the service layer.

Replace populate_instrument_for_trade (per-item) with:

template<typename Ctx>
static void populate_instruments_for_trades(
    const Ctx& ctx,
    std::vector<trade_bundle>& items);

Algorithm:

1. Group items by (product_type, trade_type_code); collect instrument UUID strings per group.
2. For each group, call the batch service method (4b) → build a map<string, trade_instrument> from results.
3. Walk items a second time; look up each instrument by UUID and set item.instrument.

Result: one DB query per represented instrument type in the portfolio, regardless of how many trades of that type exist.

Replace the hardcoded list_trades_by_node(0, 100000, ...) with a paged loop (page size 1000). Apply populate_instruments_for_trades per page. This bounds peak memory to one page of trades and their instruments.

No callers remain after 4c and Phase 6. Delete to prevent future misuse.

Confirm that bond_instrument, credit_instrument, commodity_instrument, scripted_instrument, and composite_instrument use id rather than instrument_id. Rename the C++ field to instrument_id in each struct. If the underlying SQL column is also id, rename it in the column alias in the entity mapper rather than the schema (no migration required).

After this phase every concrete instrument struct satisfies Instrument without any special-casing, and stamp_ids in Phase 3b works uniformly with no per-family branching.

Search for .id = instr_id= or .id = = patterns in instrument visitors; replace with =.instrument_id.

In trade_protocol.hpp, change get_trades_response:

// Before:
struct get_trades_response {
    bool success = true;
    std::string message;
    std::vector<trade_export_item> items;  // trade + instrument
    int total_available_count = 0;
};

// After:
struct get_trades_response {
    bool success = true;
    std::string message;
    std::vector<trading::domain::trade> trades;  // metadata only
    int total_available_count = 0;
};

The server list handler no longer calls populate_instruments_for_trades. It issues a single list_trades_by_node DB query and returns. For a 100-trade page this is one DB call instead of 100+.

struct get_trade_detail_request {
    using response_type = struct get_trade_detail_response;
    static constexpr std::string_view nats_subject =
        "trading.v1.trades.detail";
    std::string trade_id;
};

struct get_trade_detail_response {
    bool success = true;
    std::string message;
    trading::domain::trade trade;
    trading::domain::trade_instrument instrument;
};

The server handler fetches the single trade, calls the per-type service for its instrument (one DB call), and returns the bundle. This is the same logic as the old per-item populate_instrument_for_trade but executed on demand and for one trade only.

Register the new NATS subject in registrar_trades.cpp. Implement the handler method in trade_handler.hpp using the single-item instrument fetch (acceptable here: the user explicitly asked for one trade's detail).

In ClientTradeModel / PortfolioExplorerTradeModel / OrgExplorerTradeModel:

• Change the cached type from trade_export_item to trading::domain::trade.
• Remove instrument fields from the model.

In TradeController:

• openEdit / onShowDetails now receive a trading::domain::trade.
• Before opening TradeDetailDialog, issue get_trade_detail_request synchronously (the dialog is not shown until the response arrives) or asynchronously (show dialog with a loading state, populate instrument on receipt).
• Pass the returned bundle to setTradeBundle.

In TradeDetailDialog / setTradeBundle: no change to the interface — it still receives a bundle; the bundle is now fetched on demand rather than from cache.

After 6d, audit whether trade_export_item has any remaining callers. If only export_portfolio_response uses it, consider inlining the type or retaining it for that path only. If no callers remain, delete it.