Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
GET: Add parameter to GET for checking if generated fields can be retrieved #6676
I index a text field with type
Here are the steps to reproduce:
Here is what happens:
For multi-fields, the parent field is returned instead of
However, the FastVectorHighlighter relies on this functionality to highlight on multi-fields (see here), so this is not really a solution unless we want to prevent highlighting with the FastVectorHighlighter on multi-fields.
The other option is to simply catch the NumberFormatException and handle it like here: be999b1042
referenced this issue
Jul 11, 2014
A field of type
Following the discussion on pull request #6826 I checked all field mappers and tried to figure out what they should return upon GET. I will call a field "generated" if the content is only available after indexing.
Here is what I think we should do:
For some core field types (
There are currently four field types (detailed list below):
For 1-3 we simply have to implement
To make the fields configurable we could add a parameter
Pro: would be easy to do and also allow different types in plugin to very easily use the feature.
Con: This would allow users to set
For fields that are not configurable, the parameter
List of types and their category:
There is core types, root types, geo an ip.
These should be configurable:
The following two should not be configurable because they are always generated:
This should not be configurable because it is never stored:
ip an geo
Should be configurable:
Never generated and should not be configurable:
Always generated and should not be configurable:
The following should not be configurable, because they are never stored:
There are two numeric fields that are currently generated (
These should only be returned with GET (
I am now unsure if we should make the core types configurable. By configurable, I actually meant adding a parameter to the type mapping such as
I'll make a pull request without that and then maybe we can discuss further.
Just for completeness, below is a list of all ungenerated field types and how they behave with GET.
Fields with fixed behavior:
Never stored -> should never be returned via GET
Always stored -> should always be returned via GET
Stored or source enabled -> always return via GET, else never return
Stored (but independent of source) -> always return via GET, else never return
Fields that might be configurable
Special fields which can never be in the "fields" list returned by GET anyway