-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Flat index resolution #138557
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flat index resolution #138557
Conversation
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
luigidellaquila
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @idegtiarenko, LGTM
| result.fieldNames, | ||
| // Maybe if no indices are returned, retry without index mode and provide a clearer error message. | ||
| switch (indexMode) { | ||
| case IndexMode.TIME_SERIES -> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I see this logic and below is the same as for preAnalyzeMainIndices, maybe we can extract it in a method.
| ) | ||
| .build(); | ||
|
|
||
| private static final IndicesOptions FLAT_OPTIONS = IndicesOptions.builder(DEFAULT_OPTIONS) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: can we put some comments somewhere about what "flat" means? Just a block of comment text someplace that explains what the difference between these two?
| public static final String UNMAPPED = "unmapped"; | ||
|
|
||
| public static final IndicesOptions FIELD_CAPS_INDICES_OPTIONS = IndicesOptions.builder() | ||
| public static final IndicesOptions DEFAULT_OPTIONS = IndicesOptions.builder() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that you're trying to do here and I'm sure it works, but reads very visibly bi-modal. This is not necessarily for this PR, but maybe more for a follow up – can we split these two modalities through simple inheritance? I mean having the abstract base (IndexResolveBase) with protected final helper methods like createFieldCapsRequest, doResolveIndices and the abstract method resolveIndicesVersioned and have two classes deriving from it - DefaultIndexResolver and FlatWorldIndexResolver?
It will make for a better encapsulation and improved ability
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will try this idea, however I am afraid this will shit complexity into service injection part.
While resolution remains somewhat similar, the usage will still be different around how EsqlExecutionInfo#clusterInfo is populated (eg before FC call in regular mode and after FC in CPS).
| */ | ||
| public void resolveIndicesVersioned( | ||
| String indexWildcard, | ||
| public void resolveFlatIndicesVersioned( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: can we use "FlatWorld" as opposed to "Flat" please?
Flat index resolution for an esql query. This includes: