[
https://issues.apache.org/jira/browse/LUCENE-10204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17508446#comment-17508446
]
Marc D'Mello edited comment on LUCENE-10204 at 3/17/22, 9:56 PM:
-----------------------------------------------------------------
[~gsmiller] and I discussed this issue a little bit. {{ToParentBlockJoinQuery}}
does have a {{getChildQuery}} function that returns the child query which
provides this functionality. However, the problem this specific issue is trying
to solve is that it is not necessarily performant to re-run this query. The
caveat for this is the {{QueryCache}}. Maybe re-running the child query is not
as costly as we think if it uses the {{QueryCache}} to return results? Does
anyone know if the child query would be cached in this case? If not it
shouldn't be too hard to write a test that checks this.
And as a side not, if the child query is in fact cached, it it still worth it
to provide this functionality to users who do not use a query cache? Though
this seems like more of a niche use case and maybe would add unnecessary
complexity for the benefit of only a small number of users.
was (Author: mdmarshmallow):
[~gsmiller] and I discussed this issue a little bit. {{ToParentBlockJoinQuery}}
does have a {{getChildQuery}} function that returns the child query which
provides this functionality. However, the problem this specific issue is trying
to solve is that it is not necessarily performant to re-run this query. The
caveat for this is the {{QueryCache}}. Maybe re-running the child query is not
as costly as we think if it uses the {{QueryCache}} to return results? Does
anyone know if the child query would be cached in this case?
And as a side not, if the child query is in fact cached, it it still worth it
to provide this functionality to users who do not use a query cache? Though
this seems like more of a niche use case and maybe would add unnecessary
complexity for the benefit of only a small number of users.
> Support iteration of sub-matches in join queries (ToParentBlockJoinQuery /
> ToChildBlockJoinQuery)
> -------------------------------------------------------------------------------------------------
>
> Key: LUCENE-10204
> URL: https://issues.apache.org/jira/browse/LUCENE-10204
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/join
> Reporter: Greg Miller
> Priority: Minor
>
> It would be nice to be able to iterate over the "sub-matches" in these join
> queries for the purpose of faceting (or possibly other use-cases?).
> For example, we have a use-case where our query matches on "child" docs,
> using a {{ToParentBlockJoinQuery}} to "emit" the associated parents, which
> are ultimately added to our match set. But, we want to iterate over the
> matching "children" for the purpose of faceting.
> To make it concrete, consider searching over a product catalog where "offers"
> and "items" are indexed side-by-side, with the offers being represented as
> "children" of the parent items. An offer contains information like
> "condition" (new vs. used), selling price, etc. for the parent item. If we
> want to facet on "condition", we want to observe all children that matched
> the query to know if the parent item had a "new" or "used" offer (or both).
> This requires iterating over the child matches when faceting, which we cannot
> do today since the child hit information isn't retained anywhere.
> We can support this by "caching" the child hits in a bitset but there is some
> complexity when multiple join queries appear in a query structure (would need
> to logically combine various "cached" bitsets using the same boolean
> operations as in the original query structure).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
