-
Notifications
You must be signed in to change notification settings - Fork 24.7k
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
Support include_defaults in the GET-mapping API #5368
Comments
This tricky as the get field mappings api also supports wild cards ( #4367 ) which people use to get a list of all searchable fields. This is handy for suggestions of field names (i.e., a kibana panel facet configuration). Also - if you specify we could potentially add flags for this but I'm not sure it's worth it. Perhaps a documentation issue or find better url structure (using a clearer word than fields)? |
The particular use case I had was wanting to see if For wildcards, I'd say you include the object plus all of its properties.
Perhaps just a query string flag to distinguish between searchable fields and all fields, eg:
|
I have to agree with @clintongormley it would be great if it did support When I first read the documentation I did not equate
or since the default is already to only show leafs:
Since wildcards already flatten the result it would be great if the mapping for objects excludes its own |
I think the main thing that is missing here is support for So I'd be happy with just adding support for include_defaults to GET-mapping |
If that toggles including |
@Mpdreamz the change i'm suggesting is to the main get-mapping API, not the get-field-mapping API. So my request doesn't allow you to retrieve a single object field, you still have to retrieve the old mapping. However, you can get back the mapping with the defaults included. |
I'm +1 on adding an include default + filtering options (including Caveat - The get field mapping api was added and implemented in the current form (i.e., requiring at least one assigned shard) because the defaults are currently baked in the the field mapper in memory objects. To so on the master and based on the serialized representation of the _mapping, we need to have a better grip on the defaults (or if we just choose to instantiate these objects with every request). |
+1 to add the include_defaults option to get mapping API, and also makes it work for the object type field. |
If this is not gonna be fixed soon, is there any alternative way to get the default values for the object/nested type fields? Thanks. |
We just discussed it in Fixit Friday and are +1 on @bleskes 's plan. Making it an adoptme as well as a high-hanging fruit because of the described caveats... |
Rediscussed in FixItFriday - would be good to:
@rjernst is the following still true after the mapping refactoring you did?
|
cc @elastic/es-search-aggs |
The issue of still relevant. cc @elastic/es-search-aggs |
It's been a long time since this issue was discussed last. The get field mappings API has effectively been replaced by the field caps API. We have not removed the API due to the breaking nature of such a change but we would expect users to rely on field_caps to inspect the fields and their capabilities. In case mappings need to be inspected instead, get mappings is the way to go. As for adding support for include_defaults to get mappings, I doubt that it would be useful today given that most users should rely on field_caps, hence I am going to close this issue. Feel free to comment or reopen if you think otherwise. |
The get-field-mapping API only works for core field types, not for fields of type
object
ornested
:Retrieving the mapping for core fields works:
Result:
But not for fields of type
object
ornested
:Result:
The text was updated successfully, but these errors were encountered: