[
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-4212.patch
{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)
{quote}
Yeah, absolutely. I added the following:
{code}
/**
* Encapsulates facet ranges and facet queries such that their parameters
* are parsed and cached for efficient re-use.
* <p/>
* An instance of this class is initialized and kept in the request context via
the static
* method {@link
org.apache.solr.handler.component.FacetComponent.FacetContext#initContext(ResponseBuilder)}
and
* can be retrieved via {@link
org.apache.solr.handler.component.FacetComponent.FacetContext#getFacetContext(SolrQueryRequest)}
* <p/>
* This class is used exclusively in a single-node context (i.e. non distributed
requests or an individual shard
* request). Also see {@link
org.apache.solr.handler.component.FacetComponent.FacetInfo} which is
* dedicated exclusively for merging responses from multiple shards and plays no
role during computation of facet
* counts in a single node request.
*
* <b>This API is experimental and subject to change</b>
*
* @see org.apache.solr.handler.component.FacetComponent.FacetInfo
*/
public static class FacetContext {
...
}
/**
* This class is used exclusively for merging results from each shard
* in a distributed facet request. It plays no role in the computation
* of facet counts inside a single node.
*
* A related class {@link
org.apache.solr.handler.component.FacetComponent.FacetContext}
* exists for assisting computation inside a single node.
*
* <b>This API is experimental and subject to change</b>
*
* @see org.apache.solr.handler.component.FacetComponent.FacetContext
*/
public static class FacetInfo {
...
}
{code}
{quote}
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...
{quote}
Good idea. This patch has:
{code}
/**
* Initializes FacetContext using request parameters and saves it in the request
* context which can be retrieved via {@link #getFacetContext(SolrQueryRequest)}
*
* @param rb the ResponseBuilder object from which the request parameters are
read
* and to which the FacetContext object is saved.
*/
public static void initContext(ResponseBuilder rb) {
...
}
private FacetContext(List<RangeFacetRequest> allRangeFacets, List<FacetBase>
allQueryFacets) {
...
}
/**
* Return the {@link
org.apache.solr.handler.component.FacetComponent.FacetContext} instance
* cached in the request context.
*
* @param req the {@link SolrQueryRequest}
* @return the cached FacetContext instance
* @throws IllegalAccessException if no cached FacetContext instance is found in
the request context
*/
public static FacetContext getFacetContext(SolrQueryRequest req) throws
IllegalStateException {
...
}
{code}
{quote}
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?
{quote}
Done. The null check is moved inside FacetContext methods and the methods are
inlined into PivotFacetProcessor.process().
I'll commit this tomorrow morning my time unless there are any objections.
> 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-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: [email protected]
For additional commands, e-mail: [email protected]
