Default value for a string type?

Elastic Stack Elasticsearch
1

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

2

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.

3

in mySql we can use enum(0,1) and set default value to 0. The same logic i need to implement here.

4

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.

5

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.

6

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.

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:

{ "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.

7

Er, I mean to say that I would not go so far as to say. Typing on mobile....

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.