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

Disable analysis for some strings when mapping #19

Open
LosD opened this issue Dec 16, 2014 · 1 comment
Open

Disable analysis for some strings when mapping #19

LosD opened this issue Dec 16, 2014 · 1 comment

Comments

@LosD
Copy link
Contributor

LosD commented Dec 16, 2014

It turns out that the ES analyzers breaks up for easier searching. That makes a whole lot of sense in many cases, like searching description for someone mentioning a certain problem or things like that.

However, for things like labels, it is a problem. In our case, we are trying to aggregate on specific labels (used for priority), but there is a space in one of them, "Prio:Not now". This means that the terms filter will split the result into two terms, "Prio:Not" and "Now".

I haven't really analyzed (heh ;)) further, but there are probably other fields that is better left alone.

ES provides two approaches to fixing it: Disable the analyzer completely for the property, or make it into a multi_field, which can both have the original field analyzed, and a sub-field which is not analyzed, usually named raw. So in the labels case that would be labels.name (analyzed) and labels.name.raw (not analyzed).

It might be a problem to actually do something about it, as we rely on the automatic mapping right now, and changing that is not a small change. Does anyone know how ES reacts to partially mapped properties when storing documents? If that is not a problem, we could set up the mapping for the special fields and let the rest be mapped automatically.

@mihneadb
Copy link
Contributor

I avoided this because of the reason you mentioned - I left it to the automatic mapping. Let's try specifying the special fields and see what happens?

Indeed, providing explicit mapping for all the GH response types is much work.

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

No branches or pull requests

2 participants