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

Naming inconsistency: field/stored_field #20155

Closed
jpountz opened this issue Aug 25, 2016 · 4 comments
Closed

Naming inconsistency: field/stored_field #20155

jpountz opened this issue Aug 25, 2016 · 4 comments
Assignees
@jimczi
Labels
blocker >bug :Distributed/CRUD A catch all label for issues around indexing, updating and getting a doc by id. Not search. v5.0.0-beta1

Comments

@jpountz
Copy link
Contributor

jpountz commented Aug 25, 2016

The _search API has replaced fields with stored_fields in the request, but the response still uses fields. The GET API still uses fields for both the request and the response.

Relates #18943
@jimczi
Copy link
Contributor

jimczi commented Aug 25, 2016

but the response still uses fields

The fields in the response are the concatenation of stored_fields, docvalue_fields and script_fields so I think that the naming is correct.

The GET API still uses fields for both the request and the response.

We should change the request but not the response. It's also a concatenation of the other types of fields that can be requested.

I've also noticed that the documentation is not correct:

For backwards compatibility, if the fields parameter specifies fields which are not stored (`store` mapping set to
`false`), it will load the `_source` and extract it from it. This functionality has been replaced by the
<<search-request-source-filtering,source filtering>> parameter.

We don't "load the _source and extract it from it." anymore. I'll update the docs.

@jpountz
Copy link
Contributor Author

jpountz commented Aug 25, 2016

Changing the GET API to take stored_fields rather than fields sounds good to me!

@clintongormley clintongormley added the :Distributed/CRUD A catch all label for issues around indexing, updating and getting a doc by id. Not search. label Aug 25, 2016
@clintongormley
Copy link

Historically, fields was a way of getting back just the fields you were interested in. I'm thinking that we should do the same as we've done for search: remove fields and support _source, stored_fields, etc...

@jimczi
Copy link
Contributor

jimczi commented Aug 25, 2016

I'm thinking that we should do the same as we've done for search: remove fields and support _source, stored_fields, etc...

_source and source filtering are already supported. Though docvalue_fields is missing and I can rename fields to stored_fields.

@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 >bug :Distributed/CRUD A catch all label for issues around indexing, updating and getting a doc by id. Not search. v5.0.0-beta1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@clintongormley @jpountz @jimczi