Selectively indexing the contents of non-indexed objects

[Ryan_Grannell (R* Grannell)]

Hi,

I currently have an index-template set up to prevent useless or inner-property-heavy data from being indexed, as an attempt to reduce our index field-count. For example, I have certain complex response-bodies that are logged disabled by setting "enabled": false in the index template.

Unfortunately, I now need to "re-enable" some sub-properties of a non-indexed object so we can search over them, but not other sub-properties. Here's a concrete example.

Say I have logs of this format coming in:

{
	"an_object": {
		"inner_object_1": {
			"useless_prop_0": "**",
			"useless_prop_1": "**",
			
			//.
			//.
			//.

			"useless_prop_n": "**",
			"useful_prop_1": "**",
			"useful_prop_2": "**"
		},
		"inner_object_2": {
			"useless_prop_0": "**",
			"useless_prop_1": "**",
			
			//.
			//.
			//.

			"useless_prop_n": "**"
		}
	}
}

Our index-template currently disables inner_object_1 and `inner_object_2``to keep our field count down.

"properties": {
	"an_object": {
		"properties": {
			"inner_object_1": {
				"type"	:  "object",
				"enabled": false			
			}
			"inner_object_2": {
				"type"	:  "object",
				"enabled": false
			}
		}
	}
}

I'd like to index / enable:

• an_object.inner_object_1.useful_prop_1
• an_object.inner_object_1.useful_prop_2

but ignore any other junk in an_object.inner_object_1. I don't want to explicitly list every property I want disabled, as this list can change over time.

Is there some configuration available that would allow for this? For example:

"properties": {
	"an_object": {
		"properties": {
			"inner_object_1": {
				"type"	:  "object",
				"enabled": false,
				"except_please_do_not_ignore_these_properties": [ "useful_prop_1", "useful_prop_2" ]
			}
			"inner_object_2": {
				"type"	:  "object",
				"enabled": false
			}
		}
	}
}

Thanks for your help. If any clarification is needed, let me know,

Regards,
Ryan

[warkolm (Mark Walkom)]

You can use wildcards in mapping/templates, so if the useful fields contain some specific commonality in their names that might work?