Member Junction
    Preparing search index...

    Tuning + context for planPromotions.

    interface PromotionPlanOptions {
        CoverageThreshold?: number;
        ExistingColumnNames?: ReadonlySet<string>;
        LockUntilFullSync?: boolean;
    }
    Index

    Properties

    CoverageThreshold?: number

    Minimum coverage (in [0,1]) a key must clear to earn a column. Default 0 — §23: a custom key earns a column on FIRST occurrence (presence, not prevalence); appearing in even one row is enough. Raise this only if a caller deliberately wants to suppress sparse keys. The captured values are never lost regardless — they stay in the overflow JSON until promoted.

    ExistingColumnNames?: ReadonlySet<string>

    Column names that already exist on the target entity (case-insensitive). A key whose column already exists is NOT re-promoted — this is what makes the loop terminate.

    LockUntilFullSync?: boolean

    U3 — the promotion LOCK. When true, planPromotions plans NOTHING: promotion is held until a FULL sync has run since the last schema change / rediscovery. Why it's needed: after a rediscover, an INCREMENTAL sync only re-syncs CHANGED rows, so unchanged rows still carry now-vanished keys in their overflow JSON — a coverage scan over that stale mix could phantom-promote a column the source already dropped. A full sync evicts every stale key per-row (reconcileOverflowValue), so once one has been observed the coverage scan is trustworthy and the lock can clear. The ENGINE supplies the lever; MJC owns the state (it knows when a full sync completed) and pulls it. Default (undefined/false) = unlocked, preserving current behavior for callers that don't gate.