[ 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