# Workaround/alternative for "normalizer" in ES 5.1?
**URL:** https://discuss.elastic.co/t/workaround-alternative-for-normalizer-in-es-5-1/79470
**Category:** Elasticsearch
**Created:** [March 21, 2017, 4:38pm UTC](https://discuss.elastic.co/t/workaround-alternative-for-normalizer-in-es-5-1/79470 "2017-03-21T16:38:42Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@steven-collins-omega](https://discuss.elastic.co/u/steven-collins-omega)
#### Post date: [March 21, 2017, 4:38pm UTC](https://discuss.elastic.co/t/workaround-alternative-for-normalizer-in-es-5-1/79470/1 "2017-03-21T16:38:42Z")
We have first and last name keyword fields which we want to sort without regard to case. This seems to be precisely the use case for the experimental "normalizer" parameter in ES 5.2. Unfortunately because we need to use AWS Elasticsearch Service, we are restricted to ES 5.1. Is there some way to get equivalent results in ES 5.1?
In earlier versions of ES, we just specified these as "string" fields with a custom analyzer:
```
"analyzer": {
"xo_case_insensitive_sort": {
"filter": [
"lowercase"
],
"type": "custom",
"tokenizer": "keyword"
}
}
```
But obviously you can't put an analyzer on a keyword field, and if we put it as a text field we get the "Fielddata is disabled on text fields by default" exception. So one solution would be to enable fielddata, but I'm not sure that's an _intelligent_ solution. Any suggestions appreciated.
---
### Author:  [@dadoonet](https://discuss.elastic.co/u/dadoonet)
#### Post date: [March 21, 2017, 4:53pm UTC](https://discuss.elastic.co/t/workaround-alternative-for-normalizer-in-es-5-1/79470/2 "2017-03-21T16:53:35Z")
You can use ingest feature to add a new field at index time which is the lowercased version of the original one.
---
### Author:  [@steven-collins-omega](https://discuss.elastic.co/u/steven-collins-omega)
#### Post date: [March 21, 2017, 6:30pm UTC](https://discuss.elastic.co/t/workaround-alternative-for-normalizer-in-es-5-1/79470/3 "2017-03-21T18:30:25Z")
Thanks for the quick response. One issue is that we do still want to _access_ the original field with its original case. Here is an actual example of a field where we do this sort of thing (in pre-5.0 syntax):
```
"prettyEmail": {
"type": "string",
"analyzer": "english",
"fields": {
"raw": {
"type": "string",
"analyzer": "xo_case_insensitive_sort"
}
}
}
```
So a couple more questions: I would assume if we do something like you suggest we can no longer refer to the fields in code as "prettyEmail" and "prettyEmail.raw", yes? It would have to be something like "prettyEmail" and "prettyEmailRaw"? And is there a better way to do this than using the Script Processor? Again, the Lowercase Processor seems not quite right by itself because we need to hold on to the original field. I don't see anything like a "Duplicate Field Processor".
---
### Author:  [@dadoonet](https://discuss.elastic.co/u/dadoonet)
#### Post date: [March 21, 2017, 7:06pm UTC](https://discuss.elastic.co/t/workaround-alternative-for-normalizer-in-es-5-1/79470/4 "2017-03-21T19:06:44Z")
May be with a set processor first? [https://www.elastic.co/guide/en/elasticsearch/reference/current/set-processor.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/set-processor.html)
---
### Author:  [@dadoonet](https://discuss.elastic.co/u/dadoonet)
#### Post date: [March 21, 2017, 7:14pm UTC](https://discuss.elastic.co/t/workaround-alternative-for-normalizer-in-es-5-1/79470/5 "2017-03-21T19:14:10Z")
FWIW I opened
>
Which won't solve your immediate problem if added as you can't easily upgrade.
I guess you are aware of #cloud offer which is synchronized with the elastic stack release, right?
---
### Author:  [@steven-collins-omega](https://discuss.elastic.co/u/steven-collins-omega)
#### Post date: [March 21, 2017, 9:38pm UTC](https://discuss.elastic.co/t/workaround-alternative-for-normalizer-in-es-5-1/79470/6 "2017-03-21T21:38:08Z")
I'm not sure how a set processor helps... doesn't that just set a field to a fixed constant value given at pipeline definition time?
---
### Author:  [@dadoonet](https://discuss.elastic.co/u/dadoonet)
#### Post date: [March 21, 2017, 9:50pm UTC](https://discuss.elastic.co/t/workaround-alternative-for-normalizer-in-es-5-1/79470/7 "2017-03-21T21:50:30Z")
I think you can reference another field in the set value.
---
### Author:  [@steven-collins-omega](https://discuss.elastic.co/u/steven-collins-omega)
#### Post date: [March 21, 2017, 9:54pm UTC](https://discuss.elastic.co/t/workaround-alternative-for-normalizer-in-es-5-1/79470/8 "2017-03-21T21:54:20Z")
Do you happen to know the syntax for that, or have a reference to documentation of that? Thank you for all your help.
---
### Author:  [@dadoonet](https://discuss.elastic.co/u/dadoonet)
#### Post date: [March 22, 2017, 6:14am UTC](https://discuss.elastic.co/t/workaround-alternative-for-normalizer-in-es-5-1/79470/9 "2017-03-22T06:14:43Z")
Here:
[https://www.elastic.co/guide/en/elasticsearch/reference/current/accessing-data-in-pipelines.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/accessing-data-in-pipelines.html)
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [April 19, 2017, 6:15am UTC](https://discuss.elastic.co/t/workaround-alternative-for-normalizer-in-es-5-1/79470/10 "2017-04-19T06:15:00Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.