# Default value for a string type? **URL:** \ **Category:** Elasticsearch\ **Created:** [July 30, 2016, 6:59pm UTC](https://discuss.elastic.co/t/default-value-for-a-string-type/56798 "2016-07-30T18:59:14Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![parithiban](https://avatars.discourse-cdn.com/v4/letter/p/3bc359/32.png) [@parithiban](https://discuss.elastic.co/u/parithiban)\ **Post date:** [July 30, 2016, 6:59pm UTC](https://discuss.elastic.co/t/default-value-for-a-string-type/56798/1 "2016-07-30T18:59:14Z")
HI Everyone, I am having a user mapping . if the user has registered paid status will be 0. and if the user chooses a product paid status will be 1. Here is the sample mapping: ``` { "user": { "mappings": { "user_profile": { "properties": { "firstName": { "type": "string" }, "lastName": { "type": "string" }, "is_paid" :{ "type" : integer } } } } } } ``` How to make a default value for "is\_paid" to be 0. I no need to insert the is\_paid value while register but after payment successful i will update it to 1 ---
**Author:** ![Glen\_Smith](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/glen_smith/32/111656_2.png) [@Glen\_Smith](https://discuss.elastic.co/u/Glen_Smith)\ **Post date:** [July 30, 2016, 7:30pm UTC](https://discuss.elastic.co/t/default-value-for-a-string-type/56798/2 "2016-07-30T19:30:54Z")
What behavior do you want to expose by setting this value? You will certainly not be able to actually modify the source document so that when "is\_paid" is not in the document you posted, it is stored with the fields added. If what you need is the ability to _find_ documents that were indexed without any value for "is\_paid", then you can easily check search for documents where [the field does not exist](https://www.elastic.co/guide/en/elasticsearch/reference/2.3/query-dsl-missing-query.html). ---
**Author:** ![parithiban](https://avatars.discourse-cdn.com/v4/letter/p/3bc359/32.png) [@parithiban](https://discuss.elastic.co/u/parithiban)\ **Post date:** [July 30, 2016, 7:36pm UTC](https://discuss.elastic.co/t/default-value-for-a-string-type/56798/3 "2016-07-30T19:36:26Z")
in mySql we can use enum(0,1) and set default value to 0. The same logic i need to implement here. ---
**Author:** ![Glen\_Smith](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/glen_smith/32/111656_2.png) [@Glen\_Smith](https://discuss.elastic.co/u/Glen_Smith)\ **Post date:** [July 30, 2016, 8:20pm UTC](https://discuss.elastic.co/t/default-value-for-a-string-type/56798/4 "2016-07-30T20:20:04Z")
Elasticsearch isn't a plugin RDB replacement. You'll have to adapt. If you have places in code where you are finding documents with "is\_paid" zero, you'll have to update your search accordingly, as mentioned. If you have application code that creates documents without setting a value for this field, but elsewhere expects a value to be set, therein relying on an implementation detail in the storage layer, that's just sloppy application design. ---
**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:** [July 30, 2016, 8:35pm UTC](https://discuss.elastic.co/t/default-value-for-a-string-type/56798/5 "2016-07-30T20:35:53Z")
I would go so far as to say it is sloppy, just highly reliant on some feature of a storage layer. Default values is a fairly common feature in RDBMSes. Elasticsearch has null\_value which is kind of similar, but different. Though Glen's point that stands in general: elasticsearch isnt like an RDBMS and if you try and make shoe horns things youd do in an RDBMS into elasticsearch they don't always work. It does different stuff because it is a different thing. ---
**Author:** ![Glen\_Smith](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/glen_smith/32/111656_2.png) [@Glen\_Smith](https://discuss.elastic.co/u/Glen_Smith)\ **Post date:** [July 30, 2016, 9:43pm UTC](https://discuss.elastic.co/t/default-value-for-a-string-type/56798/6 "2016-07-30T21:43:39Z")
> [@nik9000](#): > > I would go so far as to say it is sloppy, just highly reliant on some feature of a storage layer. I shall rephrase using language which doesn't have such judgmental tone. Including in the application design an abstraction layer that encapsulates that dependency might be deferred by some as a "premature optimization", and it's certainly a school of thought that the proper time to provide that kind of abstraction is when you actually have to interface to the _second_ protocol. This would seem to be that time, and it's an opportunity to improve the modularity of the application design. > [@nik9000](#): > > Elasticsearch has null\_value which is kind of similar, but different. Indeed. null\_value or exists. Choosing the most appropriate for the scenario was the reason for my original question about what behavior was desired. I passed along the `exists` solution because it's actually more comprehensively applicable than `null_value`. That is, if you are going to index two documents: ```auto { "first_name": "warren", "is_paid": null} { "first_name": "francis"} ``` if the mapping provides a `null_value` for the "is\_paid" field, searching for documents which have the designated `null_value` will only return the first document, but if the mapping does _not_ provide a `null_value`, then searching for bool.must\_not exists: {"field": "is\_paid"} will find them both. ---
**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:** [July 31, 2016, 12:47am UTC](https://discuss.elastic.co/t/default-value-for-a-string-type/56798/7 "2016-07-31T00:47:06Z")
> [@nik9000](#): > > I would go so far as to say it is sloppy, Er, I mean to say that I would _not_ go so far as to say. Typing on mobile.... > [@Glen\_Smith](#): > > searching for documents which have the designated null\_value will only return the first document I didn't know that! Thanks for educating me. So, yeah, personally, I'd stick the field in there in the application layer. It is much simpler. I'd have done the same thing if I was working with an RDBMS anyway because it is simpler for me to think of it as a "storage and indexing machine" than to reason about defaults being applied after the fact. ---
**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:31pm UTC](https://discuss.elastic.co/t/default-value-for-a-string-type/56798/8 "2017-07-05T22:31:29Z")