lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] [Created] (LUCENE-4757) Cleanup FacetsAccumulator API path
Date Wed, 06 Feb 2013 14:51:12 GMT
Shai Erera created LUCENE-4757:
----------------------------------

             Summary: Cleanup FacetsAccumulator API path
                 Key: LUCENE-4757
                 URL: https://issues.apache.org/jira/browse/LUCENE-4757
             Project: Lucene - Core
          Issue Type: Improvement
          Components: modules/facet
            Reporter: Shai Erera
            Assignee: Shai Erera


FacetsAccumulator and FacetRequest expose too many things to users, even when they are not
needed, e.g. complements and partitions. Also, Aggregator is created per-FacetRequest, while
in fact applied per category list. This is confusing, because if you want to do two aggregations,
e.g. count and sum-score, you need to separate the two dimensions into two different category
lists at indexing time.

It's not so easy to refactor everything in one go, since there's a lot of code involved. So
in this issue I will:

* Remove complements from FacetRequest. It is only relevant to CountFacetRequest anyway. In
the future, it should be a special Accumulator.

* Make FacetsAccumulator concrete class, and StandardFacetsAccumulator extend it and handles
all the stuff that's relevant to sampling, complements and partitions. Gradually, these things
will be migrated to the new API, and hopefully StandardFacetsAccumulator will go away.

* Aggregator is per-document. I could not break its API b/c some features (e.g. complement)
depend on it. So rather I created a new FacetsAggregator, with a bulk, per-segment, API. So
far migrated Counting and SumScore to that API.
** In the new API, you need to override FacetsAccumulator to define an Aggregator for use,
the default is CountingFacetsAggregator.

* Started to refactor FacetResultsHandler, which its API was guided by the use of partitions.
I added a simple {{compute(FacetArrays)}} to it, which by default delegates to the nasty API,
but overridden by specific classes. This will get cleaned further along too.

* FacetRequest has a .getValueOf() which resolves an ordinal to its value (i.e. which of the
two arrays to use). I added FacetRequest.FacetArraysSource and specialize when they are INT
or FLOAT, creating a special FacetResultsHandler which does not go back to FR.getValueOf for
every ordinal. I think that we can migrate other FacetResultsHandlers to behave like that
... at the expense of code duplication.
** I also added a TODO to get rid of getValueOf entirely .. will be done separately.

* Got rid of CountingFacetsCollector and StandardFacetsCollector in favor of a single FacetsCollector
which collects matching documents, and optionally scores, per-segment. I wrote a migration
class from these per-segment MatchingDocs to ScoredDocIDs (which is global), so that the rest
of the code works, but the new code works w/ the optimized per-segment API. I hope performance
is still roughly the same w/ these changes too.

There will be follow-on issues to migrate more features to the new API, and more cleanups
...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


Mime
View raw message