[
https://issues.apache.org/jira/browse/SOLR-12981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686976#comment-16686976
]
Jason Gerlowski commented on SOLR-12981:
----------------------------------------
The updated patch makes some improvements on the original design, but still
takes essentially the same approach. There's now a few different classes used
to represent the different sorts of facets and buckets present in a faceting
response.
* {{NestableJsonFacet}} - represents "query" facets. Has a domain count getter
and can have nested subfacets. Parent of BucketJsonFacet.
* {{BucketBasedJsonFacet}} - the top level entry for a "terms" or "range"
facet. Provides access to allBuckets, numBuckets, before, after, between
properties. Also
* {{BucketJsonFacet}} - the individual buckets for a "terms" or "range" facet.
Like its parent NestableJsonFacet, it can have subfacets
* {{HeatmapJsonFacet}} - represents "heatmap" facets.
Having separate classes for the different types of facets makes the interfaces
a lot cleaner, generally. (e.g. {{getMinX()}} is only on HeatmapJsonFacet
objects, {{getVal()}} is only on {{BucketJsonFacet}} objects, etc.).
The downside of this approach though, as I touched on in an earlier comment, is
that the JSON response for faceting requests isn't 100% unambiguous,
semantically. The json faceting code doesn't reserve any of its own keywords-
if users name their facets "val", or "minX", or any other of a few semantically
meaningful words, then the parsing done by this patch will break down.
One workaround for this would be to make the JSON response less ambiguous by
adding a "type" field to make explicit the type of each (sub)facet. Another
workaround would involve restricting the facet-names that users can specify. I
think both of these would be A Good Thing for json faceting, though I won't
tackle them here. I think the simplest approach is to make this limitation
clear in the documentation. If a user for some reason absolutely can't change
their facet naming, they just won't be able to take advantage of these new
helper classes and can parse their response manually as they have up to this
point.
> Better support JSON faceting responses in SolrJ
> -----------------------------------------------
>
> Key: SOLR-12981
> URL: https://issues.apache.org/jira/browse/SOLR-12981
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java, SolrJ
> Affects Versions: 7.5, master (8.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Attachments: SOLR-12981.patch, SOLR-12981.patch
>
>
> SOLR-12947 created JsonQueryRequest to make using the JSON request API easier
> in SolrJ. SOLR-12965 is adding faceting support to this request object.
> This subtask of SOLR-12965 involves providing a way to parse the JSON
> faceting responses into easy-to-use SolrJ objects.
> Currently the only option for users is to manipulate the underlying NamedList
> directly. We should create a "JsonFacetingResponse" in the model of
> ClusteringResponse, SuggesterResponse, TermsResponse, etc. and add an
> accessor to {{QueryResponse}} for getting at the faceting results.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
