I'm using ElasticSearch 5.1 and elasticsearch.js 5.0. We have many different applications in production, which may have our platform default indices or custom ones. And we don't know their names. For new indices, I was able to add the following dynamic_template using indices.putTemplate():
var elasticsearch = require('elasticsearch');
var client = new elasticsearch.Client({ /*...*/ });
var params = {
//...
"body" : {
"template":"*",
"settings":{
"index.mapper.dynamic":true
//...
},
"mappings":{
"_default_":{
"properties":{
//...
},
"dynamic_templates":[{
"template_purchases_inner_fields": {
"path_match":"purchases.*",
"mapping": { "include_in_all": false }
}
}
//, ...
]
}
}
}
};
client.indices.putTemplate(params,function(err,resp){})
However, the Index templates docs say
Templates are only applied at index creation time. Changing a template will have no impact on existing indices
The Dynamic templates docs say
New templates can be appended to the end of the list with the PUT mapping API
The PUT mapping API has some examples, none of which fit to my scenario. An answer using indices.putMapping() would be extra helpful, but not necessary. Thanks for your time!
[Edited on 8-21-2017, Solar Eclipse day] This is the code I tried to change it through the JS API:
var dynamicTemplates = [{
"template_purchases_inner_fields": {
"path_match": "purchases.*",
"mapping": { "include_in_all": false}
}
}
//...
];
params = { body: { "dynamic_templates": dynamicTemplates }};
params.index = "_all";
params.type = "_default_";
//...
client.indices.putMapping(params,function(err,resp){})
And this is the code through Linux curl, w/ the properties field removed. Please notice that you should re-add here other templates not to override the previous ones:
curl -XPUT http://localhost:9200/_all/_default_/_mapping -d "{\"_default_\":{\"dynamic_templates\":[{\"template_purchases_inner_fields\":{\"mapping\":{\"include_in_all\":false},\"path_match\":\"purchases.*\"}}]}}"
Checking on elasticsearch-head, on both cases, the mapping was updated on existing indices too, as if it worked. However, the include_in_all=false behavior was not achieved, meaning we could still see results on searching _all on records containing the inner objects under purchases.* on existing indices.
Related items:
