# ES5.0a1: The \[string\] type is removed in 5.0. You should now use either a \[text\] or \[keyword\] field instead for field

**URL:** <https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305>\
**Category:** Elasticsearch\
**Created:** [April 13, 2016, 8:22pm UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305 "2016-04-13T20:22:07Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![gquintana](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gquintana/32/48441_2.png) [@gquintana](https://discuss.elastic.co/u/gquintana)\
**Post date:** [April 13, 2016, 8:22pm UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/1 "2016-04-13T20:22:07Z")

</div>

Hello,

I am just trying out Elasticsearch 5.0 Alpha 1, I can not create an index because type string is removed.

```
$ curl -XPUT "http://localhost:9200/monument?pretty" --data-binary @monument.settings.json
{
  "error" : {
    "root_cause" : [ {
      "type" : "mapper_parsing_exception",
      "reason" : "Failed to parse mapping [monument]: The [string] type is removed in 5.0. You should now use either a [text] or [keyword] field instead for field [appellation_courante]"
    } ],
    "type" : "mapper_parsing_exception",
    "reason" : "Failed to parse mapping [monument]: The [string] type is removed in 5.0. You should now use either a [text] or [keyword] field instead for field [appellation_courante]",
    "caused_by" : {
      "type" : "illegal_argument_exception",
      "reason" : "The [string] type is removed in 5.0. You should now use either a [text] or [keyword] field instead for field [appellation_courante]"
    }
  },
  "status" : 400
}

```

This is a huge change, is it a removal or a deprecation? What's the difference between current string type and new text type?

---

<div class="post-metadata">

**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\
**Post date:** [April 13, 2016, 8:45pm UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/2 "2016-04-13T20:45:49Z")

</div>

Yes, it is a huge change. [text](https://www.elastic.co/guide/en/elasticsearch/reference/master/text.html) is much like what string was - it is tokenized and analyzed. [keyword](https://www.elastic.co/guide/en/elasticsearch/reference/master/keyword.html) is still analyzed but isn't tokenized - or, rather, it is always tokenized as a single token. It is similar to `not_analyzed` from older versions.

We did the split because the two things turned out to be more different then they seem. For instance - `keyword` happily support `doc_values`, the on disk column wise storage used for aggregations (defaults to `true`). `text` still, sadly, only support `fielddata`, the in memory column wise storage used for aggregations (default to `false` because it likes to fill your heap).

There ought to be a blog post that'll explain it better than I can. I can't find it now so it probably doesn't exist yet. But it will exist soon. I promise.

---

<div class="post-metadata">

**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\
**Post date:** [April 13, 2016, 10:27pm UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/3 "2016-04-13T22:27:08Z")

</div>

There was a discussion at [https://github.com/elastic/elasticsearch/issues/11901](https://github.com/elastic/elasticsearch/issues/11901)

I slightly disagree, it's not a big change from the perspective of internal field processing.

The confusion is in ES \< 5, where you have plenty of combinations to setup "text" fields:

- analyzed strings
- not\_analyzed strings
- keyword analyzer for one token generation
- plus fiddling with norms, doc\_values etc.

Now with ES 5, it is easier, especially for beginners:

- `text` fields consist always of analyzed strings, not suitable for aggregations
- `keyword` fields are single tokens, without norms, docvalued for aggregations

Note that Lucene is doing "the right thing" behind the scenes, where you previously had to study the effects of lots of knobs manually to turn on and off in your mapping setup.

---

<div class="post-metadata">

**Author:** ![gquintana](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gquintana/32/48441_2.png) [@gquintana](https://discuss.elastic.co/u/gquintana)\
**Post date:** [April 14, 2016, 6:29am UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/4 "2016-04-14T06:29:35Z")

</div>

My question was more about the string/text difference than keyword/text. I regret this backward compatibility break. May I suggest to alias string=text (if possible)?

How are the existing indices (built with v2.x), with mappings containing string type, handling incoming documents? Does using text vs string type change the internal data structure ? Same for index templates, what if during migration I have a template containing a string type.

---

<div class="post-metadata">

**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\
**Post date:** [April 14, 2016, 8:39am UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/5 "2016-04-14T08:39:29Z")

</div>

The new `text` is different from `string`. So `string` can not be aliased and is banned for good reasons, because nobody should continue to use the `string` type in expectation to make it work again somehow. The result is prone to be different and would lead to conflicts, annoyance, frustrations etc.

Yes, `text` is determined to work on a different internal data structure, it does no longer allow `not_analyzed`, no doc values e.g.

Mappings and index templates have to be migrated, yes. Re-indexing everything is not decent but unavoidable IMHO.

---

<div class="post-metadata">

**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\
**Post date:** [April 14, 2016, 2:26pm UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/6 "2016-04-14T14:26:51Z")

</div>

> [@jprante](#):
>
> Mappings and index templates have to be migrated, yes.

I believe there is automatic migration for both. You can absolutely open a 2.x index in 5.0. It'd be crazy not to do.

---

<div class="post-metadata">

**Author:** ![gquintana](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gquintana/32/48441_2.png) [@gquintana](https://discuss.elastic.co/u/gquintana)\
**Post date:** [April 15, 2016, 7:01am UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/7 "2016-04-15T07:01:01Z")

</div>

Why is this automatic migration not applied when manually creating an index (in my example, monument.settings.json contains a mapping used with 2.2)? For v5. 0, it could just raise a deprecation warning.

Thanks for your explanation though

---

<div class="post-metadata">

**Author:** ![jpountz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jpountz/32/45836_2.png) [@jpountz](https://discuss.elastic.co/u/jpountz)\
**Post date:** [April 18, 2016, 1:48pm UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/8 "2016-04-18T13:48:52Z")

</div>

5.0 should automatically upgrade simple string mapping definitions to text/keyword. Could you share the mapping of your `appellation_courante` field?

---

<div class="post-metadata">

**Author:** ![gquintana](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gquintana/32/48441_2.png) [@gquintana](https://discuss.elastic.co/u/gquintana)\
**Post date:** [April 18, 2016, 4:23pm UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/9 "2016-04-18T16:23:16Z")

</div>

It's type string with analyzer french.

Gérald

---

<div class="post-metadata">

**Author:** ![jpountz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jpountz/32/45836_2.png) [@jpountz](https://discuss.elastic.co/u/jpountz)\
**Post date:** [April 19, 2016, 4:02pm UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/10 "2016-04-19T16:02:12Z")

</div>

I opened a PR: [https://github.com/elastic/elasticsearch/pull/17861](https://github.com/elastic/elasticsearch/pull/17861)

---

<div class="post-metadata">

**Author:** ![gquintana](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gquintana/32/48441_2.png) [@gquintana](https://discuss.elastic.co/u/gquintana)\
**Post date:** [May 9, 2016, 6:15pm UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/11 "2016-05-09T18:15:58Z")

</div>

Thanks for fixing that.  
Just checked 5.0A2, it works smoothly now.

---

<div class="post-metadata">

**Author:** ![jpountz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jpountz/32/45836_2.png) [@jpountz](https://discuss.elastic.co/u/jpountz)\
**Post date:** [May 9, 2016, 7:10pm UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/12 "2016-05-09T19:10:09Z")

</div>

Awesome, thanks!

---

<div class="post-metadata">

**Author:** ![gquintana](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gquintana/32/48441_2.png) [@gquintana](https://discuss.elastic.co/u/gquintana)\
**Post date:** [May 11, 2016, 7:10am UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/13 "2016-05-11T07:10:10Z")

</div>

Well I cried "victory" too early:

Here are some mapping tests with 5.0A2

This is OK  
PUT /product  
{  
"mappings": {  
"product": {  
"properties": {  
"code": {  
"type": "string"  
}  
}  
}  
}  
}

But this fails:  
PUT /product  
{  
"mappings": {  
"product": {  
"properties": {  
"code": {  
"type": "string",  
"include\_in\_all": false  
}  
}  
}  
}  
}

And even if not really usefull, the following fails as well:  
PUT /product  
{  
"mappings": {  
"product": {  
"properties": {  
"code": {  
"type": "string",  
"null\_value": "unknown"  
}  
}  
}  
}  
}

This one is really strange:  
PUT produits  
{  
"mappings": {  
"produit": {  
"properties": {  
"nom": {  
"type": "string"  
},  
"fournisseur": {  
"type": "object",  
"properties": {  
"nom": {  
"type": "string",  
"index": "analyzed",  
"null\_value": "inconnu"  
},  
"pays": {  
"type": "string",  
"index": "not\_analyzed"  
}  
}  
}  
}  
}  
}  
}

Raises an error on the field "nom":  
{  
"error": {  
"root\_cause": [  
{  
"type": "mapper\_parsing\_exception",  
"reason": "Failed to parse mapping [produit]: The [string] type is removed in 5.0. You should now use either a [text] or [keyword] field instead for field [nom]"  
}  
],  
"type": "mapper\_parsing\_exception",  
"reason": "Failed to parse mapping [produit]: The [string] type is removed in 5.0. You should now use either a [text] or [keyword] field instead for field [nom]",  
"caused\_by": {  
"type": "illegal\_argument\_exception",  
"reason": "The [string] type is removed in 5.0. You should now use either a [text] or [keyword] field instead for field [nom]"  
}  
},  
"status": 400  
}

But when you remove the "fournisseur" field (with the problematic null\_value), there isn't any problem anymore:  
PUT produits  
{  
"mappings": {  
"produit": {  
"properties": {  
"nom": {  
"type": "string"  
}  
}  
}  
}  
}  
is OK.

---

<div class="post-metadata">

**Author:** ![gquintana](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gquintana/32/48441_2.png) [@gquintana](https://discuss.elastic.co/u/gquintana)\
**Post date:** [May 11, 2016, 7:44am UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/14 "2016-05-11T07:44:54Z")

</div>

The last problem comes from the fact that I have 2 "nom" fields: "nom" and "fournisseur.nom": my fault!  
Yet the error message could have been clearer.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 5, 2017, 10:52pm UTC](https://discuss.elastic.co/t/es5-0a1-the-string-type-is-removed-in-5-0-you-should-now-use-either-a-text-or-keyword-field-instead-for-field/47305/15 "2017-07-05T22:52:35Z")

</div>