It does look like there is an issue with the _explain end point & the
has_child query . I encourage you to report it
here: Issues · elastic/elasticsearch · GitHub . Please post
CURLs to reproduce it. This will make it much easier to investigate.
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: Issues · elastic/elasticsearch · GitHub . Please post
CURLs to reproduce it. This will make it much easier to investigate.
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: Issues · elastic/elasticsearch · GitHub . Please post
CURLs to reproduce it. This will make it much easier to investigate.
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 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.
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.
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?
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?
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.
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.
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?
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.
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.
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?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
