# Case-insensitive sort
**URL:** https://discuss.elastic.co/t/case-insensitive-sort/2975
**Category:** Elasticsearch
**Created:** [May 26, 2010, 2:55am UTC](https://discuss.elastic.co/t/case-insensitive-sort/2975 "2010-05-26T02:55:29Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Phil\_Hagelberg\_2](https://discuss.elastic.co/u/Phil_Hagelberg_2)
#### Post date: [May 26, 2010, 2:55am UTC](https://discuss.elastic.co/t/case-insensitive-sort/2975/1 "2010-05-26T02:55:29Z")
I'm trying to get some fields to perform case-insensitive sort.
{"index":
{"analysis":
{"analyzer":
{"text":
{"tokenizer": "standard",
"filter":["standard","lowercase"]},
"sortable":
{"tokenizer":"keyword",
"filter":["lowercase"]}}}}}
If I set my field to {"index": "not\_analyzed", "analyzer":
"sortable"}, then it sorts in a case-sensitive manner. But if I drop
the "index" setting and use the default ("analyzed"), then it
correctly sorts case-insensitively. This is bewildering to me because
all other lucene-based systems I've worked with have warned that if a
field is analyzed, it can't be used for sorting at all.
So how is it that Elastic Search is able to get around this
limitation? And why does it break when I set it to "not\_analyzed"?
thanks,
Phil
---
### Author:  [@Phil\_Hagelberg\_2](https://discuss.elastic.co/u/Phil_Hagelberg_2)
#### Post date: [May 26, 2010, 3:13am UTC](https://discuss.elastic.co/t/case-insensitive-sort/2975/2 "2010-05-26T03:13:42Z")
> If I set my field to {"index": "not\_analyzed", "analyzer":
> "sortable"}, then it sorts in a case-sensitive manner. But if I drop
> the "index" setting and use the default ("analyzed"), then it
> correctly sorts case-insensitively. This is bewildering to me because
> all other lucene-based systems I've worked with have warned that if a
> field is analyzed, it can't be used for sorting at all.
So I think I might actually have figured it out--since I'm telling it
to use an analyzer which performs no tokenization, it's still able to
perform the sorting. But telling it "no analysis" also means "no
filtering", which means my lowercasing isn't applied. IOW it's not
analysis that interferes with sorting in the first place.
Is that correct?
-Phil
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [May 26, 2010, 6:31am UTC](https://discuss.elastic.co/t/case-insensitive-sort/2975/3 "2010-05-26T06:31:27Z")
Yea, when you set not\_analyzed, then the it won't apply an analyzer on it,
regardless which one you configure on it. In this case, you can set it to
analyzed, and keep the sortable analyzer to use.
On Wed, May 26, 2010 at 6:13 AM, Phil Hagelberg [phil@hagelb.org](mailto:phil@hagelb.org) wrote:
> > If I set my field to {"index": "not\_analyzed", "analyzer":
> > "sortable"}, then it sorts in a case-sensitive manner. But if I drop
> > the "index" setting and use the default ("analyzed"), then it
> > correctly sorts case-insensitively. This is bewildering to me because
> > all other lucene-based systems I've worked with have warned that if a
> > field is analyzed, it can't be used for sorting at all.
>
> So I think I might actually have figured it out--since I'm telling it
> to use an analyzer which performs no tokenization, it's still able to
> perform the sorting. But telling it "no analysis" also means "no
> filtering", which means my lowercasing isn't applied. IOW it's not
> analysis that interferes with sorting in the first place.
>
> Is that correct?
>
> -Phil
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 4:23am UTC](https://discuss.elastic.co/t/case-insensitive-sort/2975/4 "2017-07-06T04:23:48Z")