Move search source parsing and serializing to data#59919
Move search source parsing and serializing to data#59919flash1293 merged 20 commits intoelastic:masterfrom
Conversation
src/plugins/data/public/index.ts
Outdated
| SearchStrategyProvider, | ||
| ISearchSource, | ||
| SearchSource, | ||
| parseSearchSource, |
There was a problem hiding this comment.
@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.
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.
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) |
| indexPatterns: IndexPatternsContract, | ||
| config: SavedObjectConfig | ||
| ) { | ||
| const clearSavedIndexPattern = !!config.clearSavedIndexPattern; |
There was a problem hiding this comment.
I couldn't find any reference to this functionality, seems like this is safe to remove
…urce-serialization
…urce-serialization
…urce-serialization
| // TODO: should an intercepror have a destroy method? | ||
| this.searchInterceptor = searchInterceptor; | ||
| }, | ||
| parseSearchSource: parseSearchSource(indexPatterns), |
There was a problem hiding this comment.
nit: what about calling this createSearchSource on the contract ?
nreese
left a comment
There was a problem hiding this comment.
maps changes lgtm
code review
peteharverson
left a comment
There was a problem hiding this comment.
Edit to transform plugin LGTM
cjcenizal
left a comment
There was a problem hiding this comment.
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 |
pgayvallet
left a comment
There was a problem hiding this comment.
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.
| export interface SavedObjectKibanaServices { | ||
| savedObjectsClient: SavedObjectsClientContract; | ||
| indexPatterns: IndexPatternsContract; | ||
| search: DataPublicPluginStart['search']; |
There was a problem hiding this comment.
NIT: use ISearchStart instead.
| ...doc, | ||
| ...cloneDeep(doc), |
There was a problem hiding this comment.
Was this necessary due to a change in this PR, or is it just a fix/cleanup?
There was a problem hiding this comment.
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.
probably fine to keep it there
| savedObject: SavedObject, | ||
| config: SavedObjectConfig | ||
| config: SavedObjectConfig, | ||
| createSearchSource: DataPublicPluginStart['search']['createSearchSource'] |
There was a problem hiding this comment.
NIT: ISearchStart['createSearchSource']
There was a problem hiding this comment.
Tried to do this initially, but ISearchStart is not exported from the data plugin.
There was a problem hiding this comment.
@elastic/kibana-app-arch ^ any reason for that?
kertal
left a comment
There was a problem hiding this comment.
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_objectplugin to thedata_plugin. The current infrastructure using theSavedObjectclass 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:
clearSavedIndexPatternoption was removed because it seems like it's completely unusedparseSearchSourcefunction 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 (indexbeing 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 likeparseSearchSourceand the legacy import will be deprecated with 8.0 IIRCparseSearchSourceis also doing the job ofhydrateIndexPatternnow - this is part of the previous point.