Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Rename fields to stored_fields and add docvalue_fields #18943

Closed
clintongormley opened this issue Jun 17, 2016 · 3 comments
Closed

Rename fields to stored_fields and add docvalue_fields #18943

clintongormley opened this issue Jun 17, 2016 · 3 comments
Assignees
@jimczi
Labels
blocker >breaking good first issue low hanging fruit :Search/Search Search-related issues that do not fall into other categories v5.0.0-alpha5

Comments

@clintongormley
Copy link
Contributor

As of #15017 the fields parameter will no longer try to retrieve fields from the _source but will only return stored fields. This is a breaking change and there is nothing to warn the user that their response may well be different.

Instead, let's rename fields to stored_fields and throw an exception if the user uses fields.

Also, add docvalue_fields as an adjunct to fielddata_fields
@clintongormley clintongormley added >breaking blocker good first issue low hanging fruit help wanted adoptme :Search/Search Search-related issues that do not fall into other categories v5.0.0-alpha4 labels Jun 17, 2016
@jimczi jimczi self-assigned this Jun 17, 2016
@jimczi jimczi removed the help wanted adoptme label Jun 17, 2016
@kimchy
Copy link
Member

kimchy commented Jun 17, 2016

we could also maybe throw a nice exception, if the field is stored, we can suggest stored_fields, and if not, we can suggest source filtering?

@jimczi jimczi mentioned this issue Jun 21, 2016
Merged
@jimczi jimczi mentioned this issue Jun 22, 2016
Closed
@jpountz
Copy link
Contributor

jpountz commented Jun 24, 2016

Should we make fields a deprecated alias for stored_fields? Sure this makes things trappy if users used to retrieve _source using fields, but on the other hand we documented since 1.0 that fields should only be used for stored fields only: we are breaking all users of the fields option rather than only those who used it to retrieve fields from source?

@pickypg
Copy link
Member

pickypg commented Jun 24, 2016

I think both should be deprecated aliases for the other side. It's trappy, but it at least allows people that are using those fields properly to get the right thing without an issue. Then remove them in 6.0.

We should still throw an exception for bad usage, but presumably that check is in there anyway just because it has to be to ensure we do the right thing.

@jimczi jimczi closed this as completed in afe99fc Jul 4, 2016
@jimczi jimczi mentioned this issue Jul 25, 2016
Merged
@jpountz jpountz mentioned this issue Aug 25, 2016
Closed
@jimczi jimczi mentioned this issue Aug 25, 2016
Merged
jimczi added a commit that referenced this issue Sep 13, 2016
@jimczi
Fixed naming inconsistency for fields/stored_fields in the APIs (#20166)
1764ec5 
This change replaces the fields parameter with stored_fields when it makes sense.
This is dictated by the renaming we made in #18943 for the search API.

The following list of endpoint has been changed to use `stored_fields` instead of `fields`:
* get
* mget
* explain

The documentation and the rest API spec has been updated to cope with the changes for the following APIs:
* delete_by_query
* get
* mget
* explain

The `fields` parameter has been deprecated for the following APIs (it is replaced by _source filtering):
* update: the fields are extracted from the _source directly.
* bulk: the fields parameter is used but fields are extracted from the source directly so it is allowed to have non-stored fields.

Some APIs still have the `fields` parameter for various reasons:
* cat.fielddata: the fields paramaters relates to the fielddata fields that should be printed.
* indices.clear_cache: used to indicate which fielddata fields should be cleared.
* indices.get_field_mapping: used to filter fields in the mapping.
* indices.stats: get stats on fields (stored or not stored).
* termvectors: fields are retrieved from the stored fields if possible and extracted from the _source otherwise.
* mtermvectors:
* nodes.stats: the fields parameter is used to concatenate completion_fields and fielddata_fields so it's not related to stored_fields at all.

Fixes #20155
jimczi added a commit that referenced this issue Sep 13, 2016
@jimczi
Fixed naming inconsistency for fields/stored_fields in the APIs (#20166)
c7d4151 
This change replaces the fields parameter with stored_fields when it makes sense.
This is dictated by the renaming we made in #18943 for the search API.

The following list of endpoint has been changed to use `stored_fields` instead of `fields`:
* get
* mget
* explain

The documentation and the rest API spec has been updated to cope with the changes for the following APIs:
* delete_by_query
* get
* mget
* explain

The `fields` parameter has been deprecated for the following APIs (it is replaced by _source filtering):
* update: the fields are extracted from the _source directly.
* bulk: the fields parameter is used but fields are extracted from the source directly so it is allowed to have non-stored fields.

Some APIs still have the `fields` parameter for various reasons:
* cat.fielddata: the fields paramaters relates to the fielddata fields that should be printed.
* indices.clear_cache: used to indicate which fielddata fields should be cleared.
* indices.get_field_mapping: used to filter fields in the mapping.
* indices.stats: get stats on fields (stored or not stored).
* termvectors: fields are retrieved from the stored fields if possible and extracted from the _source otherwise.
* mtermvectors:
* nodes.stats: the fields parameter is used to concatenate completion_fields and fielddata_fields so it's not related to stored_fields at all.

Fixes #20155
jimczi added a commit that referenced this issue Sep 13, 2016
@jimczi
Fixed naming inconsistency for fields/stored_fields in the APIs (#20166)
c2498c6 
This change replaces the fields parameter with stored_fields when it makes sense.
This is dictated by the renaming we made in #18943 for the search API.

The following list of endpoint has been changed to use `stored_fields` instead of `fields`:
* get
* mget
* explain

The documentation and the rest API spec has been updated to cope with the changes for the following APIs:
* delete_by_query
* get
* mget
* explain

The `fields` parameter has been deprecated for the following APIs (it is replaced by _source filtering):
* update: the fields are extracted from the _source directly.
* bulk: the fields parameter is used but fields are extracted from the source directly so it is allowed to have non-stored fields.

Some APIs still have the `fields` parameter for various reasons:
* cat.fielddata: the fields paramaters relates to the fielddata fields that should be printed.
* indices.clear_cache: used to indicate which fielddata fields should be cleared.
* indices.get_field_mapping: used to filter fields in the mapping.
* indices.stats: get stats on fields (stored or not stored).
* termvectors: fields are retrieved from the stored fields if possible and extracted from the _source otherwise.
* mtermvectors:
* nodes.stats: the fields parameter is used to concatenate completion_fields and fielddata_fields so it's not related to stored_fields at all.

Fixes #20155
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jimczi jimczi

Labels
blocker >breaking good first issue low hanging fruit :Search/Search Search-related issues that do not fall into other categories v5.0.0-alpha5
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@kimchy @clintongormley @jpountz @pickypg @jimczi