[
https://issues.apache.org/jira/browse/SOLR-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14379043#comment-14379043
]
Yonik Seeley commented on SOLR-7214:
------------------------------------
bq. I'm thinking that while this new way of passing parameters to facetting is
good, we'll still need to support the old way to avoid any pains for users
currently doing it the old way.
Agree. I think we need to support the facet.field=myfield pretty much forever.
bq. If this new implementation supports all Solr needs, then let's simply have
a layer that can parse parameters into a JSON format that will be provided to
it.
Internally, there's not much JSON... for flexibility we parse it as soon as we
can and then it lives in SolrQueryRequest:
public Map<String,Object> getJSON();
So it's a map of string to Obect, where Object can be another Map, a List, or a
primitive such as Long, Double, Boolean, etc.
So a FacetFieldParser class looks at the generic Map<String,Object> and creates
a FacetField instance:
{code}
public class FacetField extends FacetRequest {
String field;
long offset;
long limit = 10;
long mincount = 1;
boolean missing;
boolean numBuckets;
String prefix;
String sortVariable;
SortDirection sortDirection;
FacetMethod method;
boolean allBuckets; // show cumulative stats across all buckets (this can
be different than non-bucketed stats across all docs because of multi-valued
docs)
[...]
{code}
The FacetField instance can create a FacetProcessor to actually do the faceting
work on an actual index.
For those familiar with how Queries work in Lucene/Solr:
{code}
FacetParser == QueryParser // FacetFieldParser, FacetRangeParser,
FacetQueryParser are subclasses
FacetRequest == Query // FacetField, FacetRange, FacetQuery are
subclasses
FacetProcessor == Scorer // FacetFieldProcessor, FacetRangeProcessor,
FacetQueryProcessor are subclasses
{code}
At the top level of a distributed search, a FaceRequest (like FacetField), can
create a FacetMerger to handle merging responses from shards.
bq. If this new implementation supports all Solr needs, then let's simply have
a layer that can parse parameters into a JSON format that will be provided to
it.
See the LegacyFacet class as an example of something that does conversions
between styles. It convers to the Map<String,Object>
bq. Also, it seems like the description of the FacetModule is "Heliosearch
Faceting", is this intended?
Oversight. I just committed a rename.
We still need to handle SolrTestCaseHS as well (HS stands for HelioSearch).
Some of that class should prob just go back into SolrTestCaseJ4, but some of it
(the client stuff) might make sense somewhere else.
> JSON Facet API
> --------------
>
> Key: SOLR-7214
> URL: https://issues.apache.org/jira/browse/SOLR-7214
> Project: Solr
> Issue Type: New Feature
> Reporter: Yonik Seeley
> Attachments: SOLR-7214.patch
>
>
> Overview is here: http://yonik.com/json-facet-api/
> The structured nature of nested sub-facets are more naturally expressed in a
> nested structure like JSON rather than the flat structure that normal query
> parameters provide.
> Goals:
> - First class JSON support
> - Easier programmatic construction of complex nested facet commands
> - Support a much more canonical response format that is easier for clients to
> parse
> - First class analytics support
> - Support a cleaner way to do distributed faceting
> - Support better integration with other search features
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
