Feature requests: alias for types and support multiple child types in has_child/top_child queries

Elastic Stack Elasticsearch
1

Dear all,

I have been trying out ElasticSearch parent-child relation index. In our
use case, the parent type is relatively small while the child type can be
very large. It seems beneficial for index creation/maintenance to break up
the child type into multiple small types. The problem is that 'top_child'
and 'has_child' queries do not allow more than one child type to be used
although specifying multiple types works like a charm in a usual query.

So my question is: if specifying multiple child types in
has_child/top_child queries is not supported, is it reasonably easy to
implement? This seems to be a logic extension of the current support for
query against multiple types. It should be a useful feature to many others,
and better yet, if aliases are allowed to be created for types, with this
we can simply use an alias as child_type in the has_child/top_child
queries, behind the scene queries are fired against multiple child types.

Many thanks in advance!

Junjun

--

2

For has_children, you can get this functionality now by
combining multiple has_child queries together by a boolean query. In case
of top_children it's somewhat difficult - you can try using the same
approach, but it might produce slightly different result in terms
of scoring.

On Tuesday, December 11, 2012 8:59:45 PM UTC-8, Junjun Zhang wrote:

Dear all,

I have been trying out Elasticsearch parent-child relation index. In our
use case, the parent type is relatively small while the child type can be
very large. It seems beneficial for index creation/maintenance to break up
the child type into multiple small types. The problem is that 'top_child'
and 'has_child' queries do not allow more than one child type to be used
although specifying multiple types works like a charm in a usual query.

So my question is: if specifying multiple child types in
has_child/top_child queries is not supported, is it reasonably easy to
implement? This seems to be a logic extension of the current support for
query against multiple types. It should be a useful feature to many others,
and better yet, if aliases are allowed to be created for types, with this
we can simply use an alias as child_type in the has_child/top_child
queries, behind the scene queries are fired against multiple child types.

Many thanks in advance!

Junjun

--

3

Thanks for the suggestions. I will definitely test it out and update the
list how it went in case some might be interested to know. It would be nice
this will be supported natively.
Junjun
On Dec 15, 2012 3:37 PM, "Igor Motov" imotov@gmail.com wrote:

For has_children, you can get this functionality now by
combining multiple has_child queries together by a boolean query. In case
of top_children it's somewhat difficult - you can try using the same
approach, but it might produce slightly different result in terms
of scoring.

On Tuesday, December 11, 2012 8:59:45 PM UTC-8, Junjun Zhang wrote:

Dear all,

I have been trying out Elasticsearch parent-child relation index. In our
use case, the parent type is relatively small while the child type can be
very large. It seems beneficial for index creation/maintenance to break up
the child type into multiple small types. The problem is that 'top_child'
and 'has_child' queries do not allow more than one child type to be used
although specifying multiple types works like a charm in a usual query.

So my question is: if specifying multiple child types in
has_child/top_child queries is not supported, is it reasonably easy to
implement? This seems to be a logic extension of the current support for
query against multiple types. It should be a useful feature to many others,
and better yet, if aliases are allowed to be created for types, with this
we can simply use an alias as child_type in the has_child/top_child
queries, behind the scene queries are fired against multiple child types.

Many thanks in advance!

Junjun

--

--

4

I too am very interested in this feature. As Junjun mentions, this would
help separate type management from query specification. Correct me if I'm
wrong, but since specifying multiple types is already supported wouldn't
this be a relatively easy feature to implement?

Thanks again!

--