-
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
Move search source parsing and serializing to data #59919
Move search source parsing and serializing to data #59919
Conversation
src/plugins/data/public/index.ts
Outdated
@@ -311,6 +311,8 @@ export { | |||
SearchStrategyProvider, | |||
ISearchSource, | |||
SearchSource, | |||
parseSearchSource, |
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 This PR is not ready for review from the app arch team yet, but before cleaning up the implementation I want to make sure the approach is sound. The two utility functions added to the data
plugin are:
async function parseSearchSource(
searchSourceJson: string,
references: SavedObjectReference[],
indexPatterns: IndexPatternsContract
): SearchSource;
function serializeSearchSource(searchSource: ISearchSource): { searchSourceJSON: string, references: SavedObjectReference[] };
Should these be exposed via contract instead (especially because parsing the search source requires the index patterns service, so we could wire that up within the data plugin instead of passing it in from the consumer)?
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.
IMO either approach works, though I do agree it would be nice to provide a version that already works with index patterns.
This is a bit subjective, but in general I think we often sacrifice a clean contract by statically exporting so many things, so I’m personally not opposed to putting both in the lifecycle contract (even the static one). If things change in the future, it is easier to move something from stateful > static than it is to go from static > stateful.
Plus, from a DX perspective it feels like this would be nice living alongside the other SearchSource stuff in the lifecycle contract
That said, another way we’ve addressed these scenarios is to build it to be stateless/static, but then offer a “prewired” version in the lifecycle contract. (So basically combining both approaches). In the rare case that someone prefers the static version which requires additional config, they can use it.
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 prefer having it on the contract but i agree with luke that both approaches work
I will park this PR for now to focus on moving things over, will revisit in the next minor. |
Why are you abandoning this PR @flash1293? I was looking for the same kind of functionality. Is this a bit rabbit hold to go down? Or it was parked from changing priorities? What do you think the effort would be to see it through? |
@stacey-gammon this was just about changed priorities - @ppisljar already mentioned this would unblock work of the app arch team, I will work on this today and hopefully get it in a mergeable state. |
…urce-serialization
Pinging @elastic/kibana-app-arch (Team:AppArch) |
@@ -31,25 +31,19 @@ export async function hydrateIndexPattern( | |||
indexPatterns: IndexPatternsContract, | |||
config: SavedObjectConfig | |||
) { | |||
const clearSavedIndexPattern = !!config.clearSavedIndexPattern; |
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 couldn't find any reference to this functionality, seems like this is safe to remove
…urce-serialization
…urce-serialization
…urce-serialization
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
@@ -143,6 +145,7 @@ export class SearchService implements Plugin<ISearchSetup, ISearchStart> { | |||
// TODO: should an intercepror have a destroy method? | |||
this.searchInterceptor = searchInterceptor; | |||
}, | |||
parseSearchSource: parseSearchSource(indexPatterns), |
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: what about calling this createSearchSource
on the contract ?
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.
maps changes lgtm
code review
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.
Edit to transform plugin LGTM
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 looks like ES UI got pinged because of the change to Transforms. We don't maintain this so I'm just approving to unblock the PR.
@elasticmachine merge upstream |
Ping @pgayvallet - this is touching the legacy saved object import, IIRC this falls under platforms umbrella. Would you mind taking a look? |
@flash1293 ack, will take a look |
will review this today |
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.
LGTM for (futur) SavedObjectsManagement plugin changes.
Linking to #61700, as the changes in core_plugins/kibana/public/management/sections/objects/...
will need to be ported to it once this PR is merged.
@@ -65,6 +71,7 @@ export interface SavedObjectCreationOpts { | |||
export interface SavedObjectKibanaServices { | |||
savedObjectsClient: SavedObjectsClientContract; | |||
indexPatterns: IndexPatternsContract; | |||
search: DataPublicPluginStart['search']; |
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: use ISearchStart
instead.
...doc, | ||
...cloneDeep(doc), |
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.
Was this necessary due to a change in this PR, or is it just a fix/cleanup?
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 was necessary because of this PR - as applyESResp
now errors out without creating an inconsistent search source instance (as in the old implementation), https://github.com/elastic/kibana/blob/master/src/plugins/saved_objects/public/saved_object/helpers/apply_es_resp.ts#L44 becomes a problem because this information is now lost for https://github.com/elastic/kibana/pull/59919/files/babb4d6ee332d3836ba81e213073a46b986dc913#diff-c5230517ea9644f8395ec776249ed4bbR174
I'm also fine with moving the clone into applyESResp
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.
probably fine to keep it there
@@ -29,13 +28,13 @@ import { IndexPattern } from '../../../../data/public'; | |||
export async function applyESResp( | |||
resp: EsResponse, | |||
savedObject: SavedObject, | |||
config: SavedObjectConfig | |||
config: SavedObjectConfig, | |||
createSearchSource: DataPublicPluginStart['search']['createSearchSource'] |
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: ISearchStart['createSearchSource']
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.
Tried to do this initially, but ISearchStart
is not exported from the data plugin.
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.
@elastic/kibana-app-arch ^ any reason for that?
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 👍 , tested locally in Chrome 80, OsX Mojave, by working with Saved Objects in Discover / Visualize / Dashboard. Everything works as expected.
…urce-serialization
…h1293/kibana into migrate-search-source-serialization
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
…chore/put-all-xjson-together * 'master' of github.com:elastic/kibana: [EPM] Update UI copy to use `integration` (elastic#63077) [NP] Inline buildPointSeriesData and buildHierarchicalData dependencies (elastic#61575) [Maps] create NOT EXISTS filter for tooltip property with no value (elastic#62849) [Endpoint] Add link to Logs UI to the Host Details view (elastic#62852) [UI COPY] Fixes typo in max_shingle_size for search_as_you_type (elastic#63071) [APM] docs: add alerting examples for APM (elastic#62864) [EPM] Change PACKAGES_SAVED_OBJECT_TYPE id (elastic#62818) docs: fix rendering of bulleted list (elastic#62855) Exposed AddMessageVariables as separate component (elastic#63007) Add Data - Adding cloud reset password link to cloud instructions (elastic#62835) [ML] DF Analytics: update memory estimate after adding exclude fields (elastic#62850) [Table Vis] Fix visualization overflow (elastic#62630) [Endpoint][EPM] Endpoint depending on ingest manager to initialize (elastic#62871) [Remote clusters] Fix flaky jest tests (elastic#58768) [Discover] Hide time picker when an indexpattern without timefield is selected (elastic#62134) Move search source parsing and serializing to data (elastic#59919) [ML] Functional tests - stabilize typing in mml input (elastic#63091) [data.search.aggs]: Clean up TimeBuckets implementation (elastic#62123) [ML] Functional transform tests - stabilize source selection (elastic#63087) add embed flag to saved object url as well (elastic#62926) # Conflicts: # x-pack/plugins/triggers_actions_ui/public/application/components/builtin_action_types/es_index.tsx
This PR is moving the logic taking care of serializing and deserializing a search source from the
saved_object
plugin to thedata_plugin
. The current infrastructure using theSavedObject
class stays in place, but this move makes it possible to progressively move away from the class based approach to just calling the utility functions when necessary.TODOs:
Changes:
clearSavedIndexPattern
option was removed because it seems like it's completely unusedparseSearchSource
function would initialize a search source and start parsing, but in some cases throwing an error and leaving a half-initialized search source object not complying to the typescript type (index
being a string instead of an actual index pattern object). The helper introduced by this PR only returns valid search source instances, but because of that the legacy import had to be changed to not rely on the inconsistent search source object to do the conflict resolution. I chose this route because I didn't want to introduce functionality specifically for conflict resolution in a general helper likeparseSearchSource
and the legacy import will be deprecated with 8.0 IIRCparseSearchSource
is also doing the job ofhydrateIndexPattern
now - this is part of the previous point.