[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14509892#comment-14509892
]
Hoss Man commented on SOLR-4212:
--------------------------------
feedback on the latest patch...
* DateFacetProcessor and RangeFacetProcessor should be moved into
handler/component along side PivotFacetProcessor - SimpleFacts is only in the
the request subpackage for historical reasons, we shouldn't keep making that
mistake
* Why was SimpleFacets.getFacetCounts() removed completely?
** in the current patch, the existing callers of that method (FacetComponent
and MLT Handler) now have cut/paste duplicated code.
** why can't that method continue to exist (modified to use the new processors)
to eliminate this duplication?
* PivotFacetProcessor.getTaggedFacets
** why is this method returning a map of one entry (which is the tag name?)
** the parsing bugs from the last patch are gone, but the way this method is
used still has a lot of the same "parse facet params over and over again"
redundency -- although admitedly to a lesser extent -- that seems inefficient...
*** this method will be called for every facet.pivot param that has a "range"
or "query" local param
*** within this method, every facet.range / facet.query param in the request
will be parsed (again) to see if it has the specified tag.
** I still think that hanging "facets" off of pivots should follow the same
model as hanging "stats" off of pivots (as i mentioned before: see
StatsInfo.getStatsFieldsByTag)...
*** _all_ of the param parsing is done in StatsComponent.prepare, and
datastrucutres (StatsInfo) with all the information/logic needed to accumulate
stats are put in the request context
*** the main stats logic iterates over all StatsField instances to compute
stats over the entire result set
*** each facet.pivot param, as it's processed, gets the StatsInfo from the
request context and does a simple map lookup to find the relevant StatsField
instances based on it's tag
** is there a a reason not to do the same approach in this issue? ie...
*** _all_ logic related to parsing facet.range and facet.query params can be
done _once_ in FacetComponent.prepare and the resulting data structures can be
put in the request context where they can be reused.
*** no matter how many times a range facet or query facet is hung off of
something else (by tag) it doesn't need to be reparsed, the caller can just
fetch the neccessary object from the context and ask it for a
processor/accumulator/whatever to compute the results relative to a docset.
* PivotFacetProcessor.removeUnwantedQueriesAndRanges
** this is dead code correct?
* FWIW: ant precommit is currently failing because of nocommits .. not sure if
there are other precommit checks beyond that that might be problematic
> 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, 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
