DX evidence chain

[entlein]

1 kubescape_log -> 1 order_id

We ll report. under this issue the prim-keys of each kernel table.

And Im telling you AI , do not mess with me, this is pretty basic, so do not change it randomly

[ConstanzeTU]

Primary-key (ORDER BY) change — branch fix/ae-protocol-export-pxexport (2026-08-19)

Reporting per the standing rule that every change to how a forensic_db primary key is defined lands here. For these ReplacingMergeTree tables the ORDER BY is the primary/dedup key — the column set determines exactly which rows collapse.

NEW — dx_order_records (59ed1e0e6, ships aeprod71)

ENGINE = ReplacingMergeTree()
ORDER BY (order_id, src_table, time_, pod, remote_addr, path, comm, dns_name)

Rationale: one row per record dx consulted for a primary kubescape log, stamped with that log's order_id. The key is order_id-first so the panels select an order's consulted set directly; src_table + the identity tuple (time_, pod, remote_addr, path, comm, dns_name) makes each distinct consulted record its own key and lets ReplacingMergeTree collapse only exact re-stamps of the same record.

UNCHANGED (noted for completeness)

• dx_order_seeds: ORDER BY (unique_id, rule_id) — added the order_id column this session but did not change the key.
• dx_anomaly_orders: VIEW — no primary key.

[ConstanzeTU]

Primary-key (ORDER BY) change — e426be3f5 (ships aeprod72)

dx_order_seeds (ReplacingMergeTree)

- ORDER BY (unique_id, rule_id)
+ ORDER BY (order_id)

Rationale: dx computes order_id and owns the dedup granularity (hash(uniqueID)=1:1 today; finer later). The old key (unique_id, rule_id) collapsed distinct finer orders that share a uniqueID+rule (e.g. symlink→A vs symlink→B, both R1010) at the storage level. Keying on order_id stores exactly one seed per order dx opens, whatever granularity dx picks — AE stops assuming orders-per-uniqueID. dx_order_records already keys (order_id, src_table, …), so it needed no change.