[
https://issues.apache.org/jira/browse/LUCENE-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17344803#comment-17344803
]
Greg Miller commented on LUCENE-9956:
-------------------------------------
{quote}I agree it seems unreasonable now to not be able to {{get}} the things
you had {{set}} / passed to {{ctor}}
{quote}
Yeah that's fair. It's a little nuanced though I think. DDQ supports a few
different ways to create the base query and the drill down dims, some of which
are not as simple as having the user pass something in. For example, there's a
ctor that allows the user to pass in an existing DDQ and an additional Query
filter. The base query from the reference DDQ + filter becomes the new base
query. Does it really make sense to expose that directly to the user? Also, the
"standard" approach to adding drill down dimensions is to specify a dim + path,
and DDQ constructs the appropriate Query using the user-provided
{{FacetsConfig}}. Again, in these cases should we be exposing the Queries
created under the hood?
I don't think there's any harm really in exposing them, but it does feel like a
bit of an "advanced" feature. My intention isn't really to push back on adding
this functionality, more to say "let's think about it a little bit and if
{{rewrite}} is all that's really needed in this case, maybe we don't add this
stuff yet".
> Make getBaseQuery API from DrillDownQuery public
> -------------------------------------------------
>
> Key: LUCENE-9956
> URL: https://issues.apache.org/jira/browse/LUCENE-9956
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
> Affects Versions: main (9.0)
> Reporter: Gautam Worah
> Priority: Trivial
>
> It would be great if users could access the baseQuery of a DrillDownQuery. I
> think this can be useful for folks who want to access/test the clauses of a
> BooleanQuery (for example) after they've already wrapped it into a
> DrillDownQuery.
>
> Currently the {{Query getBaseQuery()}} method is package private by default.
> If this proposed change does not make sense, or if this change breaks the
> semantic of the class, I am happy to explore other ways of doing this!
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
