-
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
[Discover] Show ignored field values #115040
Changes from all commits
9765492
76e44ae
4304f55
13bb111
07c2231
983f830
8be2525
5c47379
8292e0c
6ebbf26
921bd6c
066c7aa
5349298
911cf9e
f890df2
ce17147
4f02850
afad073
7829357
18e2205
71ac26c
3dc6746
3dc160c
a746799
ddfaf53
f164811
50799bd
cc07ef4
0337baf
1fd926c
95a31c5
17ed7fa
1d2f19f
6966db1
22be128
97c4984
0e6ef91
7713e5c
81f2b88
9d5f174
57c0130
79abe37
1802dc7
e24d0dd
5e3974a
358b77d
3863d3b
54b03ce
88be299
267334d
0aa05b1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -55,8 +55,18 @@ export interface TabifyDocsOptions { | |
* merged into the flattened document. | ||
*/ | ||
source?: boolean; | ||
/** | ||
* If set to `true` values that have been ignored in ES (ignored_field_values) | ||
* will be merged into the flattened document. This will only have an effect if | ||
* the `hit` has been retrieved using the `fields` option. | ||
*/ | ||
includeIgnoredValues?: boolean; | ||
} | ||
|
||
// This is an overwrite of the SearchHit type to add the ignored_field_values. | ||
// Can be removed once the estypes.SearchHit knows about ignored_field_values | ||
type Hit<T = unknown> = estypes.SearchHit<T> & { ignored_field_values?: Record<string, unknown[]> }; | ||
|
||
/** | ||
* Flattens an individual hit (from an ES response) into an object. This will | ||
* create flattened field names, like `user.name`. | ||
|
@@ -65,11 +75,7 @@ export interface TabifyDocsOptions { | |
* @param indexPattern The index pattern for the requested index if available. | ||
* @param params Parameters how to flatten the hit | ||
*/ | ||
export function flattenHit( | ||
hit: estypes.SearchHit, | ||
indexPattern?: IndexPattern, | ||
params?: TabifyDocsOptions | ||
) { | ||
export function flattenHit(hit: Hit, indexPattern?: IndexPattern, params?: TabifyDocsOptions) { | ||
const flat = {} as Record<string, any>; | ||
|
||
function flatten(obj: Record<string, any>, keyPrefix: string = '') { | ||
|
@@ -109,6 +115,28 @@ export function flattenHit( | |
flatten(hit.fields || {}); | ||
if (params?.source !== false && hit._source) { | ||
flatten(hit._source as Record<string, any>); | ||
} else if (params?.includeIgnoredValues && hit.ignored_field_values) { | ||
// If enabled merge the ignored_field_values into the flattened hit. This will | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. maybe I am missing something, but shouldn't there be a check if fields are being read from fields API then? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The only case here (as stated by the comment) is, that there might be theoretically _source and fields and ignored_field_values, in which case we don't want to merge the |
||
// merge values that are not actually indexed by ES (i.e. ignored), e.g. because | ||
// they were above the `ignore_above` limit or malformed for specific types. | ||
// This API will only contain the values that were actually ignored, i.e. for the same | ||
// field there might exist another value in the `fields` response, why this logic | ||
// merged them both together. We do not merge this (even if enabled) in case source has been | ||
// merged, since we would otherwise duplicate values, since ignore_field_values and _source | ||
// contain the same values. | ||
Object.entries(hit.ignored_field_values).forEach(([fieldName, fieldValue]) => { | ||
if (flat[fieldName]) { | ||
// If there was already a value from the fields API, make sure we're merging both together | ||
if (Array.isArray(flat[fieldName])) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: I think this would be more readable if it was all one
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have mixed feelings around that. I feel making the 2nd if (displayKey && fieldsToShow.includes(key)) {
pairs.push([displayKey, formattedValue]);
} else if (!displayKey) {
pairs.push([key, formattedValue]);
} So maybe we can leave that to a democratic vote :) 🚀 - Flatten this out into one dimension as suggested above There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "I don't think it would be more readable the way you suggest, Maja, I'd like to keep it as it is" would have been a perfectly fine response |
||
flat[fieldName] = [...flat[fieldName], ...fieldValue]; | ||
} else { | ||
flat[fieldName] = [flat[fieldName], ...fieldValue]; | ||
} | ||
} else { | ||
// If no previous value was assigned we can simply use the value from `ignored_field_values` as it is | ||
flat[fieldName] = fieldValue; | ||
} | ||
}); | ||
} | ||
|
||
// Merge all valid meta fields into the flattened object | ||
|
This file was deleted.
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.
Any particular reason we don't make this default to true?
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 talked a bit in the PR description about this. I believe that the behavior of merging a response from the
fields
API with ignored values together might be more of an edge-case that we need in Discover (where users are more interested "in the document" than in the fields), thus I don't think we should have that on by default. Those values coming from that ignored API might cause other weird side-effects potentially, so I think we should make merging them into the flattened object and opt-in imho.