Creating a dynamic_template with a patch_match of arbitrary depth

Elastic Stack Elasticsearch
1

I'm indexing documents with nested objects where some of the objects
include unique ids (GUIDS). I want all such fields to be "not_analyzed."
The id fields always have an '_id' suffix however, these fields can appear
at arbitrary levels in the document hierarchy. I'm trying to come up with a
dynamic mapping template to address this so that any field of the form
"_id" regardless of the nesting depth will be marked as "not_analyzed." I
don't think there's a way to specify this as a single patch_match, but I
just wanted to confirm that I'm not missing something. In practice, I
suppose the nesting will never go deeper than let's say, 5. So I could
define 5 path_match patterns like _id, ._id, .._id...etc. Although
experience shows that the moment I do this, we'll find the need to go to 6
levels ;-). Ideally, you'd be able to specify a path in ANT-like syntax
e.g., **/_id. Maybe I'll write up an enhancement request for this.

Thanks.

-b

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/f545d11b-3ce0-4e27-9a00-7dc397d34043%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

2

On Friday, April 3, 2015 at 10:36:00 AM UTC-4, Brian Levine wrote:

I'm indexing documents with nested objects where some of the objects
include unique ids (GUIDS). I want all such fields to be "not_analyzed."
The id fields always have an '_id' suffix however, these fields can appear
at arbitrary levels in the document hierarchy. I'm trying to come up with a
dynamic mapping template to address this so that any field of the form
"_id" regardless of the nesting depth will be marked as "not_analyzed." I
don't think there's a way to specify this as a single patch_match, but I
just wanted to confirm that I'm not missing something. In practice, I
suppose the nesting will never go deeper than let's say, 5. So I could
define 5 path_match patterns like _id, ._id, .._id...etc. Although
experience shows that the moment I do this, we'll find the need to go to 6
levels ;-). Ideally, you'd be able to specify a path in ANT-like syntax
e.g., **/_id. Maybe I'll write up an enhancement request for this.

Thanks.

-b

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/3242a687-9d76-4b83-a998-69a393cb5a9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.