Conversation
Extend value_mappings so each entry can use an expr field (evaluated against source bindings) instead of a literal value. Deprecate expression_to_value_mappings and expression_to_expression_mappings ahead of 1.0 removal. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Extends the transformer spec and runtime to allow value_mappings entries to compute their mapped values via an expr (evaluated with source bindings), while preserving backward-compatible literal mappings and deprecating older expression-mapping fields.
Changes:
- Add
KeyVal.exprsupport and resolve mapped values via a new_resolve_key_valhelper in thepopulated_from+value_mappingspath. - Pre-expand shorthand
dict[str, KeyVal]values (e.g.,"A": Admin) prior toReferenceValidatornormalization to avoid normalization failures afterKeyValgains extra fields. - Add tests covering expr-valued mappings, literal backward compatibility, mutual-exclusion error, and no-match behavior.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/test_transformer/test_object_transformer_new.py | Adds integration/unit tests for expr-valued and literal value_mappings, plus error/no-match cases. |
| src/linkml_map/transformer/transformer.py | Adds preprocessing to expand shorthand KeyVal dict values before normalization. |
| src/linkml_map/transformer/object_transformer.py | Resolves value_mappings outputs via literal value or evaluated expr, with lazy bindings init. |
| src/linkml_map/datamodel/transformer_model.yaml | Adds KeyVal.expr and deprecates older expression-mapping fields in the schema. |
| src/linkml_map/datamodel/transformer_model.py | Updates generated Pydantic models/metadata to reflect KeyVal.expr and deprecations. |
Unify expression evaluation: extract _eval_expr from _derive_from_expr so _resolve_key_val shares the same eval path (including unrestricted_eval fallback). Fix KeyVal bindings type signature to Bindings | None. Fix double-space typo in deprecation message. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…g-expr # Conflicts: # src/linkml_map/datamodel/transformer_model.py # src/linkml_map/transformer/object_transformer.py
2182627 to
a9ba6ad
Compare
After the _derive_slot extraction, bindings is always initialized unconditionally in map_object, so the | None is no longer needed. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Instead of adding expr to KeyVal (which polluted the shared slot namespace and required a ReferenceValidator shim), add a dedicated expression_mappings field on ElementDerivation. KeyVal stays clean (key + value only), the _expand_keyval_dicts shim is removed, and the runtime handles expression_mappings as a fallback after value_mappings in _derive_slot. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
YAML silently coerces unquoted true/false to booleans and bare numbers to integers, causing silent lookup misses against the stringified source value. Note this in value_mappings and expression_mappings descriptions. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Hold on deprecating expression_to_value_mappingsWhile reviewing issue #99 (scalar binning for enums), we found a compelling use case for The pattern: when a slot derivation routes a numeric (or string) value to a target enum via enum_derivations:
BPCategoryEnum:
expression_to_value_mappings:
"value() <= 89": LOW
"value() >= 90 and value() <= 119": NORMAL
"value() >= 120 and value() <= 139": HIGH
"value() >= 140": VERY_HIGHThis avoids the semantic overloading problem we'd have if we reused
|
expression_to_value_mappings has a compelling use case on enum derivations for scalar binning (issue #99). Remove the deprecation and update the description to reflect the intended usage: boolean expression keys evaluated with value() for classifying incoming values into permissible values. expression_to_expression_mappings remains deprecated.
When both tables contain the same key, value_mappings (literal) should win. Locks in the documented fallthrough behavior.
Summary
value_mappingsso eachKeyValentry can use anexprfield (evaluated against source bindings) instead of a literalvalue. Specifying both is an error._resolve_key_valmethod and lazy bindings init in thepopulated_from+value_mappingspath_expand_keyval_dictspreprocessing to handleReferenceValidatornormalization whenKeyValhas more than two fieldsexpression_to_value_mappingsandexpression_to_expression_mappingsin the schema ahead of 1.0 removalCloses #165
Test plan
uuid5()and source field bindingsvalueandexprset raises🤖 Generated with Claude Code