[
https://issues.apache.org/jira/browse/LUCENE-10204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509054#comment-17509054
]
Marc D'Mello commented on LUCENE-10204:
---------------------------------------
I talked a bit about this with [~mikemccand] and it seems like the query cache
isn't necessarily guaranteed to cache TPBJQ's child query.
In addition, it seems like we used to have this feature but it was removed for
performance reasons. If this is added, I think it should definitely be an
optional feature configurable in the c'tor somehow, and TPBJQ should retain all
its original functionality and performance if this feature is not used.
> 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
