How to have _all mapping in es6 without indexing the source field

[Adam_Hawkins]

I'm trying to index a document that has 1000s of fields, i'm only interested if the search text exists in the document. not searching on the specific field.
I understand that v5 had an _all field which indexed the aggregation of text from all fields, whereas this was removed in v6 , but can be replicated using copy_to on the source field to the target field. However i don't want to index the source field as well, and I cant combine copy_to and enabled: false on the field
here's my test case which is failing in ElasticSearch service 'test'

DELETE alltest
PUT alltest
{
"mappings": {
"doc": {
"properties" : {
"all": {"type": "text"},
"firstname": {"type" : "text", "copy_to": "all", "enabled": false},
"surname": {"type" : "text", "copy_to": "all", "enabled": false}
}
}
}
}

PUT alltest/doc/1
{
"firstname": "molly",
"surname": "miggings"
}

This gives :
"reason": "Mapping definition for [firstname] has unsupported parameters: [enabled : false]"

if i make enabled : true , then molly is indexed in all and firstname, if I make type: object then molly is not indexed in all and firstname is not indexed.
I want molly indexed in all, but firstname not indexed.

[danielmitterdorfer]

Hi,

instead of disabling the field completely ("enabled": false), you can disable indexing via "index": false.

Daniel

[Adam_Hawkins]

Thanks Daniel,

That does indeed work, but the firstname & surname still register as a field though they are neither searchable or aggregatable (as seen in kibana index patterns) so contribute to the total field count which is by default capped at 1000 (index.mapping.total_fields).
Do you think it would be safe to push this up substantially to account for these fields?

[danielmitterdorfer]

Hi,

please note that these settings would also exist in the mapping even if you had set "enabled": false. As the mapping may get large in either case (several MB), for example the message body of a (full) cluster state update will become larger and in general the larger mapping will put more strain on the cluster but it might be ok for your use-case. If feasible I suggest you increase the index setting index.mapping.total_fields.limit accordingly in a test cluster first to see how it copes in your case. I hope that helps you move forward.

Daniel