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.

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

[savedObjects] change the number mappings to be 'long' #3913

Merged
merged 1 commit into from
May 21, 2015

Conversation

spalger
Copy link
Contributor

@spalger spalger commented May 21, 2015

Fixes #3882

The import currently doesn't set the mapping for saved objects, but it really doesn't
need to since all of the field types match the defaults for their contents. This aligns hits: and version: fields with the defaults as well.

Opened #3912 to provide a more future-proof solution.

Since JavaScript numbers can't actually be integers we don't really care about
the difference between int and long, but since the long is the default type it
makes things more frictionless
rashidkpc added a commit that referenced this pull request May 21, 2015
[savedObjects] change the number mappings to be 'long'
@rashidkpc rashidkpc merged commit 1cc344b into elastic:master May 21, 2015
@spalger spalger deleted the fix/3882 branch June 12, 2015 00:57
@hawko2600
Copy link

The released version of 4.3.0 contains this bug (the fix is missing)

@biolds
Copy link

biolds commented Feb 5, 2016

+1, it's the same for master

@spalger
Copy link
Contributor Author

spalger commented Feb 5, 2016

Yes, this was reverted in 39f56d6 because of the unintented side effects it caused. We can't simply change the mapping we send to elasticsearch without providing a migration of some sort for existing mappings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MergeMappingException exception while importing exported dashboard
4 participants