[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616990#comment-14616990
]
Hoss Man commented on SOLR-4212:
--------------------------------
bq. In this patch, the doc set is calculated once in
RangeFacetProcessor.getFacetRangeCounts and passed down to the rangeCount
method.
...good catch.
bq. I changed FacetContext.getFacetContext method to throw
IllegalStateException instead of IllegalAccessException.
yeah, my bad -- sorry about that.
----
The current patch looks really solid to me, only one thing i think we
definitely need to clean up (and a few less important nitpicks/concerns) ...
{quote}
I have created a new FacetContext class which holds all parsed range facets and
query facets and also has a map of tag vs list of parsed facets such that we
can do quick lookups by tag.
bq. (Either that, or just use the existing FacetInfo class for this since
that's pretty much it's current purpose. Is the reason you didn't already do
that because FacetInfo isn't currently in the single node code path?)
Yeah, that’s pretty much it. The current FacetInfo is exclusively used for
merging distributed results which makes it a bit inflexible for our
requirements.
{quote}
...can you please add some specifics to the FacetContext and FacetInfo class
jdocs that point to eachother and explain/compare/contrast the differences (ie:
explain when/why each is used so people trying to make sense of various bits of
code get the distinction)
----
Nit-Picks...
* looking at how FacetContext.setFacetContext is used, i'm wondering if a
cleaner API would be to make the FacetContext constructor private, and replace
setFacetContext with something like...{code}
public static void initFacetContext(ResponseBuilder rb) {
if (rb.getContext().containsKey(MAGIC_KEY)) {
throw new IllegalStateException("Context must only be initialized once per
request...");
}
// ...Parse params into things like RangeFacetRequest & build Lists & Maps
for context
}
{code}...that seems like it would be safer and guard against agcidental missuse
of redundent "new FacetContext" or "FacetContext.setFacetContext(...)" by devs
in the future
* with the new FacetContext object, PivotFacetProcessor.getTaggedQueryFacets
and PivotFacetProcessor.getTaggedRangeFacets seem fairly unneccessary -- if we
just move the "if null use emptyList()" logic into the FacetContext equivilents
can't we just refactor them into oblivion?
> 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: 5.3, Trunk
>
> 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-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-6686-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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
