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

Add support for long and keyword in dict-type #3515

Merged
merged 1 commit into from
Feb 2, 2017

Conversation

ruflin
Copy link
Member

@ruflin ruflin commented Feb 2, 2017

As keyword is the default currently not mapping was added. For the human reader now a mapping is predefined.

For long dict-types a dynamic mapping is added as is done for text

@@ -54,6 +54,7 @@
}
}
},
"fields": {},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe:

"fields": {
     "properties": {}
}

looks a bit more clear.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed

})

if field.get("dict-type") == "keyword":
properties[field["name"]] = {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should also be done for "long" and "text", then.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes. It applies to all dict-type entries.

As keyword is the default currently not mapping was added. For the human reader now a mapping is predefined.

For long dict-types a dynamic mapping is added as is done for text
@andrewkroh andrewkroh merged commit f0dc62d into elastic:master Feb 2, 2017
@ruflin ruflin deleted the dict-type-enhancement branch February 2, 2017 20:08
tsg pushed a commit to tsg/beats that referenced this pull request Jun 9, 2017
This were introduced in elastic#3515, but I think they cause issues like
the one in elastic#4483, at least in recent versions of ES.

We already removed these in master, but I didn't
realize the 5.x branches are affected.

Fixes elastic#4483.
tsg pushed a commit to tsg/beats that referenced this pull request Jun 13, 2017
This were introduced in elastic#3515, but I think they cause issues like
the one in elastic#4483, at least in recent versions of ES.

We already removed these in master, but I didn't
realize the 5.x branches are affected.

Fixes elastic#4483.

(cherry picked from commit a373306)
monicasarbu pushed a commit that referenced this pull request Jun 14, 2017
…iles (#4498)

* Remove empty properties from the template files

This were introduced in #3515, but I think they cause issues like
the one in #4483, at least in recent versions of ES.

We already removed these in master, but I didn't
realize the 5.x branches are affected.

Fixes #4483.

(cherry picked from commit a373306)

* update testing env
leweafan pushed a commit to leweafan/beats that referenced this pull request Apr 28, 2023
…plate files (elastic#4498)

* Remove empty properties from the template files

This were introduced in elastic#3515, but I think they cause issues like
the one in elastic#4483, at least in recent versions of ES.

We already removed these in master, but I didn't
realize the 5.x branches are affected.

Fixes elastic#4483.

(cherry picked from commit d9fc986)

* update testing env
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.

3 participants