[
https://issues.apache.org/jira/browse/LUCENE-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826570#comment-13826570
]
Shai Erera commented on LUCENE-5339:
------------------------------------
{quote}
Hmm, that's iffy. First off, IW also calls .storableFields(), and
it's not defined which will be called first, and we need to add both
storable and indexable fields.
{quote}
Why are storableFields() related? None of the facet fields are also storable. I
think we should only override indexableFields(). The part about reusing fields
is a bigger problem though, so maybe your Document.rewrite() idea (like Query)
could work... I just think that extending IW for this minor task (adding
facets) is too much. I like the way you add FacetField to a Document, I just
prefer to avoid the IW extension (at this point). So if we can pursue
Doc.rewrite(), that may be good. Otherwise, maybe we could bring back
FacetFields, only you won't add all CPs, but rather add FacetField one by one
and then you can call createDoc() or something.
bq. Really this is just adding complexity for a minor gain?
We can do this later. I just think that indexing the dimension is in 99% of the
cases redundant. I prefer that the 1 app out there that might be interested in
that do hard work, rather than we enforce more ordinals in the BDV for all
faceted search apps.
bq. OK, I added an OrdinalsReader abstraction
Thanks!
{quote}
I pulled out a base class (TaxonomyFacets) for all the taxonomy based
facet methods, to share some code.
{quote}
Awesome!
> 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
