A slot_derivation that sets value: (a constant) and no populated_from gets a synthesized populated_from equal to its own slot name when the spec is derived. The semantic validator then checks that synthesized name against the source class, does not find a column by that name — correctly, since it is a constant — and reports an error.
Deriving a spec against a source schema shows the substitution:
raw: associated_visit -> populated_from=None, value='TOY BASELINE'
derived: associated_visit -> populated_from='associated_visit', value='TOY BASELINE'
map-data validates the derived spec (cli/cli.py in _pre_flight_validate), so validator.py's populated_from not in source_class_slots check fires on the synthesized value and emits severity="error".
The transformation itself is unaffected — the constants land in the output exactly as intended — but every constant-valued slot derivation produces one error line per entity. A small toy pipeline here emits 192 of them per run.
That volume is the actual problem: a genuine spec error is invisible inside a wall of spurious ones, which defeats the purpose of the check on real runs.
Skipping the source-class check when value is set would fix it, though distinguishing a synthesized populated_from from a user-declared one seems more robust — the validator currently cannot tell them apart, and that distinction probably matters for other checks too.
Seen with 0.5.4rc1; the same behavior is present in 0.5.3.
A
slot_derivationthat setsvalue:(a constant) and nopopulated_fromgets a synthesizedpopulated_fromequal to its own slot name when the spec is derived. The semantic validator then checks that synthesized name against the source class, does not find a column by that name — correctly, since it is a constant — and reports an error.Deriving a spec against a source schema shows the substitution:
map-datavalidates the derived spec (cli/cli.pyin_pre_flight_validate), sovalidator.py'spopulated_from not in source_class_slotscheck fires on the synthesized value and emitsseverity="error".The transformation itself is unaffected — the constants land in the output exactly as intended — but every constant-valued slot derivation produces one error line per entity. A small toy pipeline here emits 192 of them per run.
That volume is the actual problem: a genuine spec error is invisible inside a wall of spurious ones, which defeats the purpose of the check on real runs.
Skipping the source-class check when
valueis set would fix it, though distinguishing a synthesizedpopulated_fromfrom a user-declared one seems more robust — the validator currently cannot tell them apart, and that distinction probably matters for other checks too.Seen with 0.5.4rc1; the same behavior is present in 0.5.3.