Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to configure eager fielddata loading for _timestamp field via PUT mapping API for type with existing mapping #6958

Closed
shikhar opened this issue Jul 22, 2014 · 4 comments

Comments

@shikhar
Copy link
Contributor

shikhar commented Jul 22, 2014

When creating a new index, if I have eager fielddata loading configured for the _timestamp field, that sticks.

However when updating this setting via the PUT mapping API, although the request is acknowledged when I check the mapping via GET, fielddata configuration for that field is blank.

I have been able to successfully configure it for other fields via the PUT mapping API, though. Seems like this problem may be specific to the special underscore-prefixed fields, though I've only really tried _timestamp.

@shikhar shikhar changed the title Unable to configure eager fielddata loading for _timestamp field via PUT-Mapping-API for type with existing mapping Unable to configure eager fielddata loading for _timestamp field via PUT mapping API for type with existing mapping Jul 22, 2014
@clintongormley
Copy link

Hi @shikhar

What version are you using? Also, could you provide a small curl recreation of the problem?

thanks

@shikhar
Copy link
Contributor Author

shikhar commented Aug 20, 2014

curl -XPOST localhost:9200/test -d '{
    "settings" : {
        "number_of_shards" : 1
    },
    "mappings" : {
        "type1" : {
            "_timestamp" : { "enabled" : true },
            "properties" : {
                "field1" : { "type" : "string", "index" : "not_analyzed" }
            }
        }
    }
}'
curl -XPUT 'localhost:9200/test/type1/_mapping' -d '{                                                                                                            
        "type1" : {
            "_timestamp" : { "enabled" : true, "fielddata": { "loading": "eager" } },
            "properties" : {
                "field1" : { "type" : "string", "index" : "not_analyzed", "fielddata": { "loading": "eager" } }
            }
        }
    }'

acknowledged: true

but:

curl -XGET 'localhost:9200/test/type1/_mapping?pretty=true'
{
  "test" : {
    "mappings" : {
      "type1" : {
        "_timestamp" : {
          "enabled" : true
        },
        "properties" : {
          "field1" : {
            "type" : "string",
            "index" : "not_analyzed",
            "fielddata" : {
              "loading" : "eager"
            }
          }
        }
      }
    }
  }
}

@shikhar
Copy link
Contributor Author

shikhar commented Aug 21, 2014

forgot to mention, this is on ES 1.3.0

@brwe
Copy link
Contributor

brwe commented Aug 21, 2014

The fielddata settings are not merged when the mapping is updated (https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/index/mapper/internal/TimestampFieldMapper.java#L280). This is similar to issue #777 and #5772. I will go through all the different root mappers and fix one by one, just have not gotten further than _ttl (#7316) yet.

@brwe brwe self-assigned this Aug 21, 2014
brwe added a commit to brwe/elasticsearch that referenced this issue Sep 5, 2014
Updates on the _timestamp field were silently ignored.
Now _timestamp undergoes the same merge as regular
fields. This includes exceptions if a prroperty cannot
be changed.
"path" and "default" cannot be changed.

closes elastic#5772
closes elastic#6958
partially fixes elastic#777
@brwe brwe closed this as completed in ee5221b Sep 8, 2014
brwe added a commit that referenced this issue Sep 8, 2014
Updates on the _timestamp field were silently ignored.
Now _timestamp undergoes the same merge as regular
fields. This includes exceptions if a property cannot
be changed.
"path" and "default" cannot be changed.

closes #5772
closes #6958
closes #7614
partially fixes #777
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants