Using _exlpain on parent / child

Should it be possible to use explain API with a has_child query?

I have a parent document that has child documents. I'm trying to run an
explain on a query like this:

{
"query": {
"has_child": {
"type": "child",
"query": {
"bool": {
"must": [
{
"term": {
"path": "/top"
}
}
]
}
}
}
}
}

And the result I'm getting is:

{"error":"ElasticSearchIllegalStateException[has_child filter hasn't executed properly]","status":500}

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Hi Rotem,

It does look like there is an issue with the _explain end point & the
has_child query . I encourage you to report it
here: https://github.com/elasticsearch/elasticsearch/issues/ . Please post
CURLs to reproduce it. This will make it much easier to investigate.

In the mean time - search based explain does work
( http://www.elasticsearch.org/guide/reference/api/search/explain/ ) . As
an alternative you can debug by querying child types directly.

Cheers,
Boaz

On Monday, July 8, 2013 4:57:09 PM UTC+2, Rotem wrote:

Should it be possible to use explain API with a has_child query?

I have a parent document that has child documents. I'm trying to run an
explain on a query like this:

{
"query": {
"has_child": {
"type": "child",
"query": {
"bool": {
"must": [
{
"term": {
"path": "/top"
}
}
]
}
}
}
}
}

And the result I'm getting is:

{"error":"ElasticSearchIllegalStateException[has_child filter hasn't executed properly]","status":500}

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Thanks Boaz.

Actually I'm not really interested in debugging the query. My real
intention is to know if a document matches a query.
But I can't use the percolator since it doesn't support parent / child
documents.
And issuing the search query in question with an added _id constraint may
also be a problem since the document might still not be updated in the
index (in my use case i need to check it right after indexing).
So I was hoping the _explain endpoint will do the trick (all I need is to
see if there's a match).
Any other ideas maybe?

On Tuesday, July 9, 2013 4:15:22 PM UTC+3, Boaz Leskes wrote:

Hi Rotem,

It does look like there is an issue with the _explain end point & the
has_child query . I encourage you to report it here:
https://github.com/elasticsearch/elasticsearch/issues/ . Please post
CURLs to reproduce it. This will make it much easier to investigate.

In the mean time - search based explain does work (
http://www.elasticsearch.org/guide/reference/api/search/explain/ ) . As
an alternative you can debug by querying child types directly.

Cheers,
Boaz

On Monday, July 8, 2013 4:57:09 PM UTC+2, Rotem wrote:

Should it be possible to use explain API with a has_child query?

I have a parent document that has child documents. I'm trying to run an
explain on a query like this:

{
"query": {
"has_child": {
"type": "child",
"query": {
"bool": {
"must": [
{
"term": {
"path": "/top"
}
}
]
}
}
}
}
}

And the result I'm getting is:

{"error":"ElasticSearchIllegalStateException[has_child filter hasn't executed properly]","status":500}

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

BTW, issue opened:

On Tuesday, July 9, 2013 4:15:22 PM UTC+3, Boaz Leskes wrote:

Hi Rotem,

It does look like there is an issue with the _explain end point & the
has_child query . I encourage you to report it here:
https://github.com/elasticsearch/elasticsearch/issues/ . Please post
CURLs to reproduce it. This will make it much easier to investigate.

In the mean time - search based explain does work (
http://www.elasticsearch.org/guide/reference/api/search/explain/ ) . As
an alternative you can debug by querying child types directly.

Cheers,
Boaz

On Monday, July 8, 2013 4:57:09 PM UTC+2, Rotem wrote:

Should it be possible to use explain API with a has_child query?

I have a parent document that has child documents. I'm trying to run an
explain on a query like this:

{
"query": {
"has_child": {
"type": "child",
"query": {
"bool": {
"must": [
{
"term": {
"path": "/top"
}
}
]
}
}
}
}
}

And the result I'm getting is:

{"error":"ElasticSearchIllegalStateException[has_child filter hasn't executed properly]","status":500}

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Thx.

FYI - the _explain API also works in near realtime , just like search. The
reason is that it needs the tokenised version of the doc to explain the
query. You should also be aware that _explain is heavy (but maybe not too
heavy for you) which also means it is usually used for debugging and
therefore doesn't need realtime support.

Does the query contain only a has_child clause? if you so you might be able
to query the children type with the parent id.

On Tue, Jul 9, 2013 at 3:51 PM, Rotem rotem.hermon@gmail.com wrote:

BTW, issue opened:
https://github.com/elasticsearch/elasticsearch/issues/3305

On Tuesday, July 9, 2013 4:15:22 PM UTC+3, Boaz Leskes wrote:

Hi Rotem,

It does look like there is an issue with the _explain end point & the
has_child query . I encourage you to report it here: https://github.com/*
*elasticsearch/elasticsearch/**issues/https://github.com/elasticsearch/elasticsearch/issues/ . Please post CURLs to reproduce it. This will make it much easier to
investigate.

In the mean time - search based explain does work (
http://www.elasticsearch.**org/guide/reference/api/**search/explain/http://www.elasticsearch.org/guide/reference/api/search/explain/) . As an alternative you can debug by querying child types directly.

Cheers,
Boaz

On Monday, July 8, 2013 4:57:09 PM UTC+2, Rotem wrote:

Should it be possible to use explain API with a has_child query?

I have a parent document that has child documents. I'm trying to run an
explain on a query like this:

{
"query": {
"has_child": {
"type": "child",
"query": {
"bool": {
"must": [
{
"term": {
"path": "/top"
}
}
]
}
}
}
}
}

And the result I'm getting is:

{"error":"ElasticSearchIllegalStateException[has_child filter hasn't executed properly]","status":500}

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/jI0oU0BMsMU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

No, the query will be a combination of parent / child attributes. 


So if it's only near realtime the explain endpoint also doesn't fit
my use case. Is there any other way of doing this I might have
missed?

Not that I can see. Perhaps if you tell me more about your application - is
the a chance of aggregated all the child document in the parent and
percolating it? Depending on the nuances of the query it may be inaccurate
but it might also be good enough for you.

On Tue, Jul 9, 2013 at 4:21 PM, Rotem Hermon rotem.hermon@gmail.com wrote:

No, the query will be a combination of parent / child attributes.
So if it's only near realtime the explain endpoint also doesn't fit my use
case. Is there any other way of doing this I might have missed?

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/jI0oU0BMsMU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Basically I have a parent document on which I collect all kind of dynamic
counters. Each counter has a name (which can be anything and is varied) and
a value.

I need to search based on name/value combination so the counters can't be
added as an array to the parent (otherwise searches will not bring correct
results). They can be either nested or children. Children seems more
appropriate as the parent document can be big and I don't want to re-index
it on every counter update (which can happen a lot).

I also have a set of predefined queries (which combine parent attributes
and counter values). When I index (update) a parent document I need to
check if it answers to one of the predefined queries.

On Tuesday, July 9, 2013 5:29:14 PM UTC+3, Boaz Leskes wrote:

Not that I can see. Perhaps if you tell me more about your application -
is the a chance of aggregated all the child document in the parent and
percolating it? Depending on the nuances of the query it may be inaccurate
but it might also be good enough for you.

On Tue, Jul 9, 2013 at 4:21 PM, Rotem Hermon <rotem....@gmail.com<javascript:>

wrote:

No, the query will be a combination of parent / child attributes.
So if it's only near realtime the explain endpoint also doesn't fit my
use case. Is there any other way of doing this I might have missed?

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/jI0oU0BMsMU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearc...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Hi Rotem,

Yeah - parent/child is the perfect answer from a normal search & indexing
point of view.

Thinking out of the box - is realistic for you do a mget for all the
counters, inject them into the parent body in question and percolate that?
or perhaps the reverse - injecting parent attributes to counter document
and percolate all of those? to solve the searching problem relating to
search both name and value - depending on the type of search - you can
concatenate name and value and search on the combination. This works if
you're not doing numeric range queries on the values. You can also see if
you can translate the names into numbers and combine them with the counter
values. All depends on what kind of assumptions you can safely do with your
data.

I realize this is hacky - but that's the best I can offer.

Cheers,
Boaz

On Tue, Jul 9, 2013 at 4:38 PM, Rotem rotem.hermon@gmail.com wrote:

Basically I have a parent document on which I collect all kind of dynamic
counters. Each counter has a name (which can be anything and is varied) and
a value.

I need to search based on name/value combination so the counters can't be
added as an array to the parent (otherwise searches will not bring correct
results). They can be either nested or children. Children seems more
appropriate as the parent document can be big and I don't want to re-index
it on every counter update (which can happen a lot).

I also have a set of predefined queries (which combine parent attributes
and counter values). When I index (update) a parent document I need to
check if it answers to one of the predefined queries.

On Tuesday, July 9, 2013 5:29:14 PM UTC+3, Boaz Leskes wrote:

Not that I can see. Perhaps if you tell me more about your application -
is the a chance of aggregated all the child document in the parent and
percolating it? Depending on the nuances of the query it may be inaccurate
but it might also be good enough for you.

On Tue, Jul 9, 2013 at 4:21 PM, Rotem Hermon rotem....@gmail.com wrote:

No, the query will be a combination of parent / child attributes.
So if it's only near realtime the explain endpoint also doesn't fit my
use case. Is there any other way of doing this I might have missed?

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit https://groups.google.com/d/**
topic/elasticsearch/**jI0oU0BMsMU/unsubscribehttps://groups.google.com/d/topic/elasticsearch/jI0oU0BMsMU/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
elasticsearc...@**googlegroups.com.
For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/jI0oU0BMsMU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Hmmm, a bit hacky indeed but interesting ideas :slight_smile:
I'm not sure it will be valid data-wise, but definitely something to think
about.

Thanks!

On Thu, Jul 11, 2013 at 10:49 PM, Boaz Leskes b.leskes@gmail.com wrote:

Hi Rotem,

Yeah - parent/child is the perfect answer from a normal search & indexing
point of view.

Thinking out of the box - is realistic for you do a mget for all the
counters, inject them into the parent body in question and percolate that?
or perhaps the reverse - injecting parent attributes to counter document
and percolate all of those? to solve the searching problem relating to
search both name and value - depending on the type of search - you can
concatenate name and value and search on the combination. This works if
you're not doing numeric range queries on the values. You can also see if
you can translate the names into numbers and combine them with the counter
values. All depends on what kind of assumptions you can safely do with your
data.

I realize this is hacky - but that's the best I can offer.

Cheers,
Boaz

On Tue, Jul 9, 2013 at 4:38 PM, Rotem rotem.hermon@gmail.com wrote:

Basically I have a parent document on which I collect all kind of dynamic
counters. Each counter has a name (which can be anything and is varied) and
a value.

I need to search based on name/value combination so the counters can't be
added as an array to the parent (otherwise searches will not bring correct
results). They can be either nested or children. Children seems more
appropriate as the parent document can be big and I don't want to re-index
it on every counter update (which can happen a lot).

I also have a set of predefined queries (which combine parent attributes
and counter values). When I index (update) a parent document I need to
check if it answers to one of the predefined queries.

On Tuesday, July 9, 2013 5:29:14 PM UTC+3, Boaz Leskes wrote:

Not that I can see. Perhaps if you tell me more about your application -
is the a chance of aggregated all the child document in the parent and
percolating it? Depending on the nuances of the query it may be inaccurate
but it might also be good enough for you.

On Tue, Jul 9, 2013 at 4:21 PM, Rotem Hermon rotem....@gmail.comwrote:

No, the query will be a combination of parent / child attributes.
So if it's only near realtime the explain endpoint also doesn't fit my
use case. Is there any other way of doing this I might have missed?

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit https://groups.google.com/d/**
topic/elasticsearch/**jI0oU0BMsMU/unsubscribehttps://groups.google.com/d/topic/elasticsearch/jI0oU0BMsMU/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
elasticsearc...@**googlegroups.com.
For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/jI0oU0BMsMU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/jI0oU0BMsMU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.