[
https://issues.apache.org/jira/browse/LUCENE-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13822840#comment-13822840
]
Robert Muir commented on LUCENE-5339:
-------------------------------------
{quote}
Really, you're mixing optimizations (inlining dgap+vint) with ease of use. I
know (!!) that there are apps that can benefit from a different encoding scheme
(e.g. FourOnesIntEncoder). We don't need to wait until someone comes up w/ a
better default encoding scheme to introduce abstractions. I mean .. that's just
sounds crazy to me.
{quote}
How common is this, I'm curious?
Just to lend my opinion/support to this issue: imo the pure number of classes
to the faceting module can be overwhelming.
Lets take the encode/decode case: it seems to me you guys iterated a lot and
figured out vint was "the best default encoding". I'm not going to argue that
some use case could benefit from a custom encoding scheme: instead I'm going to
argue if it justifies a whole java package with 20 public classes?
So I think its fine to bake in the encoding, but with the two key methods in
those 20 classes 'protected' in the appropriate places so that an expert user
could subclass them:
{code}
decode(BytesRef buf, IntsRef values);
encode(IntsRef values, BytesRef buf);
{code}
I'd make the argument: if someone is expert enough to do this, they dont need
pre-provided concrete encoder/decoder classes anyway, they can write their own
method?
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
