[
https://issues.apache.org/jira/browse/LUCENE-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13833596#comment-13833596
]
Gilad Barkai commented on LUCENE-5339:
--------------------------------------
Been away from the issue for some time and it looks like a major progress,
Chapeau à lui
{{LabelAndValue}} & {{FacetResult}} use {{instanceof}} checks in their
{{equals}} method - is that a must?
{{FacetResult}} has a member called {{childCount}} - I think it's the number of
categories/path/labels that were encountered. The current jdocs "How many
labels were populated under the requested path" reveals implementation
(population). Perhaps exchange populated with encountered?
{{FloatRange}} and {{DoubleRange}} uses {{Math.nextUp/Down}} for infinity as
the ranges are always inclusive. Perhaps these constants for float and double
could be static final.
{{TaxonomyFacetSumFloatAssociations}} and {{TaxonomyFacetSumValueSource}} reuse
a LOT of code, can they extend one another? perhaps extract a common super for
both?
In {{TaxonomyFacets}} the parents array is saves, I could not see where it's
being used (and I think it's not used even in the older taxonomy-facet
implementation).
{{FacetConfig}} confuses me a bit, as it's very much aware of the Taxonomy, on
another it handles all the kinds of the facets.
Perhaps {{FacetConfig.build()}} could be split up, allowing each
{{FacetField.Type}} a build() method of its own, rather than every types'
building being done in the same method. It will also bring a common parent
class to all FacetField types, which I also like. As such, the taxonomy part,
with {{processFacetFields()}} could be moved to its respective Facet
implementation.
> Simplify the facet module APIs
> ------------------------------
>
> Key: LUCENE-5339
> URL: https://issues.apache.org/jira/browse/LUCENE-5339
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Attachments: LUCENE-5339.patch, LUCENE-5339.patch
>
>
> I'd like to explore simplifications to the facet module's APIs: I
> think the current APIs are complex, and the addition of a new feature
> (sparse faceting, LUCENE-5333) threatens to add even more classes
> (e.g., FacetRequestBuilder). I think we can do better.
> So, I've been prototyping some drastic changes; this is very
> early/exploratory and I'm not sure where it'll wind up but I think the
> new approach shows promise.
> The big changes are:
> * Instead of *FacetRequest/Params/Result, you directly instantiate
> the classes that do facet counting (currently TaxonomyFacetCounts,
> RangeFacetCounts or SortedSetDVFacetCounts), passing in the
> SimpleFacetsCollector, and then you interact with those classes to
> pull labels + values (topN under a path, sparse, specific labels).
> * At index time, no more FacetIndexingParams/CategoryListParams;
> instead, you make a new SimpleFacetFields and pass it the field it
> should store facets + drill downs under. If you want more than
> one CLI you create more than one instance of SimpleFacetFields.
> * I added a simple schema, where you state which dimensions are
> hierarchical or multi-valued. From this we decide how to index
> the ordinals (no more OrdinalPolicy).
> Sparse faceting is just another method (getAllDims), on both taxonomy
> & ssdv facet classes.
> I haven't created a common base class / interface for all of the
> search-time facet classes, but I think this may be possible/clean, and
> perhaps useful for drill sideways.
> All the new classes are under oal.facet.simple.*.
> Lots of things that don't work yet: drill sideways, complements,
> associations, sampling, partitions, etc. This is just a start ...
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
