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

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.

Hi,

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

Daniel

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?

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