-
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] Expose SearchSource on the server. #78383
Conversation
if (params.signal) { | ||
params.signal.addEventListener('abort', () => promise.abort()); | ||
} |
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.
@lukasolson Let me know if I got this abort logic right. I tested and AFAICT it all works as expected.
const callMsearch = getCallMsearch({ | ||
esClient: context.core.elasticsearch.client, | ||
globalConfig$: deps.globalConfig$, | ||
uiSettings: context.core.uiSettings.client, | ||
}); |
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 got simplified to a helper which could also be called outside of a route handler
/** | ||
* Unless we want all SearchSource users to provide both a KibanaRequest | ||
* (needed for index patterns) AND the RequestHandlerContext (needed for | ||
* low-level search), we need to fake the context as it can be derived | ||
* from the request object anyway. This will pose problems for folks who | ||
* are registering custom search strategies as they are only getting a | ||
* subset of the entire context. Ideally low-level search should be | ||
* refactored to only require the needed dependencies: esClient & uiSettings. | ||
*/ | ||
const fakeRequestHandlerContext = { | ||
core: { | ||
elasticsearch: { | ||
client: esClient, | ||
}, | ||
uiSettings: { | ||
client: uiSettingsClient, | ||
}, | ||
}, | ||
} as RequestHandlerContext; | ||
return this.search(fakeRequestHandlerContext, searchRequest, 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.
@lukasolson @lizozom @ppisljar We should discuss the fakeRequestHandlerContext
here -- I added it to our list to cover offline.
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 am fine moving forward with this but lets open an issue for refactoring we want to do
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.
Takeaway from our offline discussion: we will keep as-is for now as @ppisljar suggests, and discuss the proposed low-level search service changes separately.
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.
Here's the issue for discussing changes to the low-level search API: #78461
globalConfig$: this.initializerContext.config.legacy.globalConfig$, | ||
uiSettings: uiSettingsClient, | ||
}), | ||
loadingCount$: new BehaviorSubject(0), |
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.
loadingCount$
isn't really necessary on the server, so we just initialize BehaviorSubject
that never changes
@@ -140,6 +152,58 @@ export class SearchService implements Plugin<ISearchSetup, ISearchStart> { | |||
) => { | |||
return this.search(context, searchRequest, options); | |||
}, | |||
searchSource: { | |||
asScoped: async (request: KibanaRequest) => { |
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.
Accepting a KibanaRequest
was pretty much my only option for the API since it's what index patterns require on the server. The question (as outlined in the code comment below) is whether it's necessary to also require RequestHandlerContext
for the low-level search, when all of those items can already be derived from a KibanaRequest
const router = core.http.createRouter(); | ||
|
||
router.get( | ||
{ path: '/api/data_search_plugin/search_source/as_scoped', validate: false }, |
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.
These tests create a few dummy routes that can be called from the client to execute various pieces of the searchSource service on the server.
before(async () => { | ||
await esArchiver.loadIfNeeded( | ||
'../functional/fixtures/es_archiver/getting_started/shakespeare' | ||
); | ||
await PageObjects.common.navigateToApp('settings'); | ||
await PageObjects.settings.createIndexPattern('shakespeare', ''); | ||
}); |
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.
relocated to top-level before
that loads before both index patterns and search
Pinging @elastic/kibana-app-arch (Team:AppArch) |
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
5203671
to
f48dda8
Compare
@elasticmachine merge upstream |
1 similar comment
@elasticmachine merge upstream |
merge conflict between base and head |
5fca711
to
b75a84b
Compare
b75a84b
to
5aebda3
Compare
💚 Build SucceededMetrics [docs]@kbn/optimizer bundle module count
distributable file count
page load bundle size
History
To update your PR or re-run it, just comment with: |
# Conflicts: # src/plugins/data/server/server.api.md
@@ -108,7 +101,7 @@ export const searchSourceRequiredUiSettings = [ | |||
]; | |||
|
|||
export interface SearchSourceDependencies extends FetchHandlers { | |||
search: ISearchGeneric; | |||
search: (request: IEsSearchRequest, options: ISearchOptions) => Promise<IEsSearchResponse>; |
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.
@lukeelmers why did you do this change here?
ISearchGeneric
is the exact equivalent of this more explicit typescript.
Was the intention here to limit the usage of SearchSource
to DSL only?
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.
It's not quite the exact equivalent -- ISearchGeneric
returns an observable, however on the server, the low-level search returns a promise.
In order to ensure the same behavior of SearchSource
on both client & server, I had to wrap the dependency into something that always returns a promise.
That said, I did not include the ability to provide generic type params like ISearchGeneric
does, and probably should have. I will open a PR to update 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.
(Also per our offline discussion, if low-level search on the server eventually moves to returning an observable as it does on the client, we can come back and adjust 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.
PR adding the generic type params: #79608
Closes #65069
Summary
This is the final PR which exposes
SearchSource
on the server:await data.search.searchSource.asScoped(kibanaRequest);
, which returns the same API as is available on the client.Testing
This PR relies on the added functional tests to validate that everything works, as there is not currently anywhere in Kibana which uses this service on the server.
Dev Docs
The high-level search API
SearchSource
is now available on the server. Usage: