Conversation
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
|
The same issue might be addressed by #141340 |
alex-spies
left a comment
There was a problem hiding this comment.
Thanks @idegtiarenko !
Looks correct. As discussed, I prefer getting Bogdan's PR in (because I'm already fighting CI over there), which will make this obsolete, I'm afraid :/ I'll add your test, though, and will attribute to you if git permits!
| required_capability: optional_fields_nullify_tech_preview | ||
| required_capability: join_lookup_v12 |
There was a problem hiding this comment.
Probably failing bwc tests due to no new capability required here.
There was a problem hiding this comment.
The behavior is probably the correct one, but we'll disallow joins with load for now until we're certain that we always want to load from the main index (I think we do). That's #142367
| if (child instanceof EsRelation esr && esr.indexMode() == IndexMode.LOOKUP) { | ||
| newChildren.add(child); | ||
| continue; | ||
| } |
There was a problem hiding this comment.
Essentially the same fix as in Bogdan's PR https://github.com/elastic/elasticsearch/pull/141340/changes#diff-b135751577c8077e6aebc28a662beca9f604826869d1d368c60fc8f1bb0a2e4bR212-R219.
| SET unmapped_fields="nullify"\; | ||
| FROM languages | ||
| | LOOKUP JOIN languages_lookup ON language_code | ||
| | KEEP language_code, language_name, foobar |
Extracted from elastic#142863 Co-authored-by: Ievgen Degtiarenko <ievgen.degtiarenko@elastic.co>
|
Closing in favor of 222b7c3 |
This change fixes lookup queries with unknown fields executed with
SET unmapped_fields="nullify";.Such queries produced the following plan:
and could not be mapped to a physical plan.
The fix is to avoid inserting eval on top of lookup sources.
Alternatively we should consider setting eval on top of
Joininstead of individualEsRelations.Fixes: #141978