[jira] [Updated] (LUCENE-10044) Clean up unit tests for TestDrillSideways

["Sejal Pawar (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCENE-10044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sejal Pawar updated LUCENE-10044:
---------------------------------
    Description: 
All unit tests in `TestDrillSideways` currently do the same task for priming a `DrillDownQuery` and a `DrillSidewaysResult`. I would like to extract the common code here for the initialisation and capture it in `DrillSidewaysInitialiser` - a helper class which would initialise a `DrillSidewaysResult` while retaining members like `FacetsConfig` for future access.

Something similar has been implemented for `Document` creation in `DocHelper`.

  was:
The {{DrillSideways}} logic currently encapsulates, 1) the creation of multiple {{FacetsCollector}} instances, and 2) the processing of those {{FacetsCollectors into a single Facets}} instance. While I suspect this works well for most common cases, and is simple to understand, it's difficult to extend to more advanced cases.

I propose extending {{DrillSideways}} to support exposing the underlying {{FacetsCollector}} instances if the user needs them, in addition to maintaining the current functionality for all of the more common cases. Specifically, I'd like to add both the "drill down" {{FacetsCollector}} and map of dim -> {{FacetsCollector}} for "drill sideways" to the {{DrillSidewaysResult}} and {{ConcurrentDrillSidewaysResult}} classes. While it's true that a user can extend {{DrillSideways}} and override {{buildFacetsResult}} to keep track of these, it seems reasonable to provide this in {{DrillSideways}} itself so users don't need to sub-class for only this purpose.

Here are two use-cases illustrating the desire for this:
 # For certain cases, instead of actually creating a {{Facets}} instance from the {{FacetsCollector}}, I'd like to intersect the {{FacetsCollector}} matching docs with a {{TermEnum}} to do determine whether-or-not at least one match exists. This is useful for a "facet" that can only take on the values "true"/"false", and I want to make sure at least one hit has the value "true".
 # In another case, I only care about some aggregate statistics for a given facet field. For example, I want to find the min and max values. For this, I want to intersect some doc value field with a {{FacetsCollector}} and only track the min/max values I observe while iterating.

     Issue Type: Test  (was: Improvement)

> Clean up unit tests for TestDrillSideways
> -----------------------------------------
>
>                 Key: LUCENE-10044
>                 URL: https://issues.apache.org/jira/browse/LUCENE-10044
>             Project: Lucene - Core
>          Issue Type: Test
>          Components: modules/facet
>    Affects Versions: main (9.0)
>            Reporter: Sejal Pawar
>            Priority: Minor
>             Fix For: main (9.0), 8.10
>
>
> All unit tests in `TestDrillSideways` currently do the same task for priming a `DrillDownQuery` and a `DrillSidewaysResult`. I would like to extract the common code here for the initialisation and capture it in `DrillSidewaysInitialiser` - a helper class which would initialise a `DrillSidewaysResult` while retaining members like `FacetsConfig` for future access.
> Something similar has been implemented for `Document` creation in `DocHelper`.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org