Package org.elasticsearch.xpack.esql.analysis.rules

Class ResolveUnmapped

java.lang.Object
org.elasticsearch.xpack.esql.rule.Rule<LogicalPlan,LogicalPlan>
org.elasticsearch.xpack.esql.rule.ParameterizedRule<LogicalPlan,LogicalPlan,AnalyzerContext>
org.elasticsearch.xpack.esql.analysis.AnalyzerRules.ParameterizedAnalyzerRule<LogicalPlan,AnalyzerContext>
org.elasticsearch.xpack.esql.analysis.rules.ResolveUnmapped
public class ResolveUnmapped extends AnalyzerRules.ParameterizedAnalyzerRule<LogicalPlan,AnalyzerContext>
The rule handles fields that don't show up in the index mapping, but are used within the query. These fields can either be missing entirely, or be present in the document, but not in the mapping (which can happen with non-dynamic mappings). The handling strategy is driven by the AnalyzerContext.unmappedResolution() setting.

In the case of the former ones, the rule introduces EVAL missing = NULL commands (null-aliasing / null-Eval'ing).

In the case of the latter ones, it introduces field extractors in the source (where this supports it).

In both cases, the rule takes care of propagation of the aliases, where needed (i.e., through "artificial" projections introduced within the analyzer itself; vs. the KEEP/RENAME/DROP-introduced projections). Note that this doesn't "boost" the visibility of such an attribute: if, for instance, referencing a mapping-missing attribute occurs after a STATS that doesn't group by it, that attribute will remain unresolved and fail the verification. The language remains semantically consistent.