[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-4212:
----------------------------------------
Attachment: SOLR-6353-6686-4212.patch
Changes:
# DateFacetProcessor and DateFacetProcessor are moved to handler/component
package
# SimpleFacets.getFacetCounts() was removed because it would have been weird
for SimpleFacets to create and use its own sub-class
RangeFacetProcessor/DateFacetProcessor. However, in this patch I have replaced
that bit of code with a static method in FacetComponent which should eliminate
the repetition in MLTHandler.
# Now FacetComponent tries to do a similar thing as StatsComponent i.e. to
parse params in prepare method and re-use in PivotFacetProcessor. I tried many
designs before the current patch:
** Create FacetInfo in prepare method and re-use throughout. However this
doesn't work because there is no separation of concerns in the constituents of
FacetInfo. They serve a dual purpose of parsing and aggregating. So when we try
creating it in prepare it would throw NPEs inside shard requests trying to
access rb.shards.
** Create a FacetContext class which parses and keeps the params and use it in
PivotFacetProcessor. We can't use ParsedParam because it has DocSet etc which
are just not available in the prepare method.
** Finally I settled for a crude approach of enhancing FacetBase with tags and
just parsing the facet queries and ranges and putting them in the request
context. Not super happy about it but un-entangling FacetInfo and related
classes is too big a task for this issue.
* PivotFacetProcessor.removeUnwantedQueriesAndRanges was dead code and it has
been removed.
* I removed the RangeFacetAccumulator class and replaced it with a
LinkedHashMap of facetStr to RangeFacet. This RangeFacet class extends
FacetBase just like PivotFacetValue and is responsible for aggregation of a
single facet value. This increases a bit of code i.e. looping over all range
facets and aggregating but it is no different from what other facet types were
doing.
* Tests and precommit both pass.
TBH, this faceting code makes my head hurt and a massive refactoring is
required. I have some ideas around it but I chose not to do any more to avoid
scope creep. Once this is committed, we can open a few issues to clean up.
[~mmurphy3141] - I know the class names are same but what's a better name? This
patch is older than the new code and is on the same lines as
PivotFacetProcessor.
> Let facet queries hang off of pivots
> ------------------------------------
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
> Affects Versions: 4.0
> Reporter: Steve Molloy
> Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
