When is fully qualified path to a nested doc field required?


(Justin Treher) #1

When exactly should you use the fully qualified path name in the case of
standard objects, nested objects (documents), and combinations with
multi_field within?

I had an incident where my facets were not returning correctly. I traced it
back to a nested facet filter and a field name inside that nested document
that is used elsewhere in the document. When I reindexed, it "FIXED
ITSELF." I thought, fine, I will fully qualify the path to prevent whatever
issue just happened.

However, I also applied the fully qualified path to a multi_field that is
accessed via "just_name" inside the nested document. In that case, I was
not able to put the nested document path in front of it.

====Relevant chunk of mappings for this nested object=====
{
"categories": {
"type": "nested",
"properties": {
"name": {
"type": "multi_field",
"path": "just_name",
"fields": {
"name": {
"type": "string"
},
"name_special": {
"type": "string",
}
}
},
"default": {
"type": "boolean" <== this was my problem field, I use
default in a non-nested object elsewhere in the document.
}
}
}
}

====facet=====
{
"facets": {
"hierarchy": {
"terms": {
"field": "categories.name_special" <== doesn't work, have to
use "name_special" without path
},
"facet_filter": {
"term": {
"categories.default": true <== categories. prefix must be
here to prevent another field in the "parent" doc from being used. Optional?
}
},
"nested": "categories"
}
},
"size": 0
}

--
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/2771c9b0-df08-4d9e-95c7-b3b2760fafb3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Justin Treher) #2

As a follow-up, what is the default "path" applied to non-root objects?

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-object-type.html
Regarding the section "path?"

On Friday, January 24, 2014 10:38:41 AM UTC-5, Justin Treher wrote:

When exactly should you use the fully qualified path name in the case of
standard objects, nested objects (documents), and combinations with
multi_field within?

I had an incident where my facets were not returning correctly. I traced
it back to a nested facet filter and a field name inside that nested
document that is used elsewhere in the document. When I reindexed, it
"FIXED ITSELF." I thought, fine, I will fully qualify the path to prevent
whatever issue just happened.

However, I also applied the fully qualified path to a multi_field that is
accessed via "just_name" inside the nested document. In that case, I was
not able to put the nested document path in front of it.

====Relevant chunk of mappings for this nested object=====
{
"categories": {
"type": "nested",
"properties": {
"name": {
"type": "multi_field",
"path": "just_name",
"fields": {
"name": {
"type": "string"
},
"name_special": {
"type": "string",
}
}
},
"default": {
"type": "boolean" <== this was my problem field, I use
default in a non-nested object elsewhere in the document.
}
}
}
}

====facet=====
{
"facets": {
"hierarchy": {
"terms": {
"field": "categories.name_special" <== doesn't work, have to
use "name_special" without path
},
"facet_filter": {
"term": {
"categories.default": true <== categories. prefix must be
here to prevent another field in the "parent" doc from being used. Optional?
}
},
"nested": "categories"
}
},
"size": 0
}

--
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/658e5cc7-6df3-472a-b0bb-69b1f69342f0%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Binh Ly) #3

Justin:

I think you probably meant to say:

{
"facets": {
"hierarchy": {
"terms": {
"field": "categories*.name*.name_special"
},
"facet_filter": {
"term": {
"categories.default": true
}
},
"nested": "categories"
}
},
"size": 0
}

In general, when in doubt, always specify the full path in your queries.
Please give it a try and let me know if that helps.

On Friday, January 24, 2014 10:38:41 AM UTC-5, Justin Treher wrote:

When exactly should you use the fully qualified path name in the case of
standard objects, nested objects (documents), and combinations with
multi_field within?

I had an incident where my facets were not returning correctly. I traced
it back to a nested facet filter and a field name inside that nested
document that is used elsewhere in the document. When I reindexed, it
"FIXED ITSELF." I thought, fine, I will fully qualify the path to prevent
whatever issue just happened.

However, I also applied the fully qualified path to a multi_field that is
accessed via "just_name" inside the nested document. In that case, I was
not able to put the nested document path in front of it.

====Relevant chunk of mappings for this nested object=====
{
"categories": {
"type": "nested",
"properties": {
"name": {
"type": "multi_field",
"path": "just_name",
"fields": {
"name": {
"type": "string"
},
"name_special": {
"type": "string",
}
}
},
"default": {
"type": "boolean" <== this was my problem field, I use
default in a non-nested object elsewhere in the document.
}
}
}
}

====facet=====
{
"facets": {
"hierarchy": {
"terms": {
"field": "categories.name_special" <== doesn't work, have to
use "name_special" without path
},
"facet_filter": {
"term": {
"categories.default": true <== categories. prefix must be
here to prevent another field in the "parent" doc from being used. Optional?
}
},
"nested": "categories"
}
},
"size": 0
}

--
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/80582230-ec20-46e3-99ed-e7b7cb1cf031%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Justin Treher) #4

Binh -

You are correct. The pathing with nested documents definitely confuses me!
So, name.name_special doesn't work. When I apply the path, it has to be the
whole deal, categories.name.name_special. So, the only issue I am left to
resolve is that why on one version of my index is treating a
non-root/non-nested object as "just_name." I know I definitely did not
change mappings.

But if I apply the "When in doubt, use the full path" rule, it would
resolve itself anyhow I suppose, even if something screwing happened during
the generation of the dynamic mappings..

Justin

On Friday, January 24, 2014 12:06:03 PM UTC-5, Binh Ly wrote:

Justin:

I think you probably meant to say:

{
"facets": {
"hierarchy": {
"terms": {
"field": "categories*.name*.name_special"
},
"facet_filter": {
"term": {
"categories.default": true
}
},
"nested": "categories"
}
},
"size": 0
}

In general, when in doubt, always specify the full path in your queries.
Please give it a try and let me know if that helps.

On Friday, January 24, 2014 10:38:41 AM UTC-5, Justin Treher wrote:

When exactly should you use the fully qualified path name in the case of
standard objects, nested objects (documents), and combinations with
multi_field within?

I had an incident where my facets were not returning correctly. I traced
it back to a nested facet filter and a field name inside that nested
document that is used elsewhere in the document. When I reindexed, it
"FIXED ITSELF." I thought, fine, I will fully qualify the path to prevent
whatever issue just happened.

However, I also applied the fully qualified path to a multi_field that is
accessed via "just_name" inside the nested document. In that case, I was
not able to put the nested document path in front of it.

====Relevant chunk of mappings for this nested object=====
{
"categories": {
"type": "nested",
"properties": {
"name": {
"type": "multi_field",
"path": "just_name",
"fields": {
"name": {
"type": "string"
},
"name_special": {
"type": "string",
}
}
},
"default": {
"type": "boolean" <== this was my problem field, I use
default in a non-nested object elsewhere in the document.
}
}
}
}

====facet=====
{
"facets": {
"hierarchy": {
"terms": {
"field": "categories.name_special" <== doesn't work, have to
use "name_special" without path
},
"facet_filter": {
"term": {
"categories.default": true <== categories. prefix must be
here to prevent another field in the "parent" doc from being used. Optional?
}
},
"nested": "categories"
}
},
"size": 0
}

--
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/8287ec2b-f983-48ae-b5ae-26a091cddfac%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(system) #5