-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[data.search][data.indexPatterns] Expose esaggs + indexPatternLoad on the server. #84590
Conversation
1eded79
to
50f9578
Compare
@@ -42,7 +41,7 @@ export class FieldFormatsRegistry { | |||
protected metaParamsOptions: Record<string, any> = {}; | |||
protected getConfig?: FieldFormatsGetConfigFn; | |||
// overriden on the public contract | |||
public deserialize: (mapping: SerializedFieldFormat) => IFieldFormat = () => { | |||
public deserialize: FormatFactory = () => { |
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.
The public contract uses FormatFactory
, so this inconsistency caused some type issues when moving esaggs to the server.
"type": "function", | ||
} | ||
`); | ||
}); |
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.
For the agg types that already had unit tests, I added one to verify the output of toExpressionAst
}; | ||
|
||
return table; | ||
} |
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've split out a few things here that we can share on the client & server:
- The meta for the expression function definition
- The types for the function's dependencies & definition
- The request handler & logic that converts a response to a datatable
return createEsaggs({ | ||
getStartDependencies: async () => { | ||
const [, , self] = await getStartServices(); | ||
const { fieldFormats, indexPatterns, query, search } = self; | ||
return { | ||
addFilters: query.filterManager.addFilters.bind(query.filterManager), | ||
aggs: search.aggs, | ||
deserializeFieldFormat: fieldFormats.deserialize.bind(fieldFormats), | ||
indexPatterns, | ||
searchSource: search.searchSource, | ||
}; | ||
}, | ||
}); |
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.
This is the main difference between the public
and server
implementations -- basically it's a function that wires up all of the stateful dependencies on various start
contracts.
The createEsaggs
function above is much simpler: it's just responsible for retrieving the needed pieces of state from those services, and calling the helper that handles the entire request.
The goal here was to isolate differences between client & server code so that we could still share as much as possible from common
, and I've used a similar approach with indexPatternLoad
. Open to any feedback or other ideas on this.
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.
Discussing this further in this thread.
expect(result.type).toEqual('index_pattern'); | ||
expect(result.value.title).toEqual('value'); | ||
}); | ||
}); |
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.
There were already tests for indexPatternLoad
but I haven't yet added any for esaggs
-- my plan was to wait until the next PR as I'll be refactoring the args at that time anyway
if (!kibanaRequest) { | ||
throw new Error( | ||
i18n.translate('data.search.esaggs.error.kibanaRequest', { | ||
defaultMessage: | ||
'A KibanaRequest is required to execute this search on the server. ' + | ||
'Please provide a request object to the expression execution params.', | ||
}) | ||
); | ||
} |
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.
On the server we must have a KibanaRequest
or we cannot scope the dependencies of esaggs
, so any function that relies on a scoped service will need to throw if this handler is not present (since it's optional).
// eslint-disable-next-line @kbn/eslint/no-restricted-paths | ||
import type { KibanaRequest } from 'src/core/server'; |
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've tested, and so far it seems that as long as we're only importing a type from server
, it doesn't create issues in the bundle as the typescript is compiled away.
}; | ||
}, | ||
}) | ||
); |
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 moved esaggs function registration to the search service.
Did the same for indexPatternLoad in the index pattern service on the server, however kept it here on the client as there's no separate index pattern "service" that gets called in setup
Pinging @elastic/kibana-app-services (Team:AppServices) |
src/plugins/data/public/index_patterns/expressions/load_index_pattern.ts
Show resolved
Hide resolved
50f9578
to
7b09cbe
Compare
d3196c4
to
e2877dd
Compare
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]Module Count
Distributable file count
Page load bundle
History
To update your PR or re-run it, just comment with: |
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.
code LGTM
Part of #65067
Summary
This PR exposes the data plugin's
esaggs
andindexPatternLoad
expression functions on the server as a part of the effort to make esaggs available on the server. (TheindexPatternLoad
function was moved here because it will be needed for the final step of improving the semantics of the esaggs function).One complication that arose was that some of the services that
esaggs
relies on -- such as aggs, index patterns, and search source -- have slightly different contracts on the server in that they must be scoped to a specific user first. To address this, I've added an optionalkibanaRequest
handler to the expressions execution context. When executing an expression on the server, downstream consumers will need to provide this request object when making calls torun
orexecute
so that the object is made available to the expression functions that need it. Assuming it is provided, the expression should return the same value that it would on the client.Changes
esaggs
on both client & serveresaggs
code tocommon
indexPatternLoad
on both client & serveresaggs
indexPatternLoad
code tocommon
expressionName
required, and ensure each type has an assigned nameexpressionName
so you can callaggConfig.toExpressionAst()
, the output of which will be used when we refactor the esaggs arguments.Reviewers
It's recommended to ignore whitespace changes and review this commit-by-commit, as github seems to have trouble displaying the diffs correctly. It looks like a ton of changes, but in reality a lot of them are from updating each of the agg types, which involved touching a bunch of files but was otherwise pretty repetitive.
Testing
This is a refactor that should introduce no functional changes. Areas touched include the querying infrastructure that's shared among all visualizations, including TSVB and lens.