[
https://issues.apache.org/jira/browse/SOLR-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16665299#comment-16665299
]
Michael Gibney edited comment on SOLR-12922 at 10/26/18 3:48 PM:
-----------------------------------------------------------------
"more people who can implement own facet handling rather than those who can
build patched Solr" – indeed!
"wide variety or user specific facet handling logic" – sure, but I guess was
just curious about more specific use cases. Not necessary, but helpful to avoid
requiring everyone to do their own imagining of use cases.
I guess I can also weigh in on use cases here ... this issue piqued my interest
because I was interested in the ability to dynamically vary the configuration
of subfacets based on attributes of the parent bucket. A concrete example would
be:
{code:java}
json.facet={
subject_level_0: {
type: terms,
field: subject_f,
facet: {
subject_level_1: {
type: terms,
prefix: $parent,
field: subject_f,
limit: 5
}
}
}
}
{code}
Note that "$parent" for the "prefix" attribute of the subfacet is _not_
supported syntax, but is intended to denote the value of the term in the parent
bucket. The idea is to support hierarchical browsing over fields whose values
are hierarchical in nature (e.g., "United States", "United States – History",
"United States – History – 1783-1815", etc.).
So "$parent" is not supported syntax, but this plugin architecture would make
it possible to create a subclass of {{FacetFieldParser}} whose {{parse()}}
method would return a subclass of {{FacetField}} whose
{{createFacetProcessor(FacetContext fcontext)}} method could parse the parent
bucket value out of the {{FacetContext.filter}} and return a {{FacetProcessor}}
with a contextually-determined prefix ... or something like that.
More generally though, I could imagine wanting to do other types of dynamic
(parameterized and/or contextual) facet configuration, some to support very
specialized use cases, that would be much more straightforwardly and
sustainably implemented with this type of plugin architecture.
was (Author: mgibney):
"more people who can implement own facet handling rather than those who can
build patched Solr" – indeed!
"wide variety or user specific facet handling logic" – sure, but I guess was
just curious about more specific use cases. Not necessary, but helpful to avoid
requiring everyone to do their own imagining of use cases.
I guess I can also weigh in on use cases here ... this issue piqued my interest
because I was interested in the ability to dynamically vary the configuration
of subfacets based on attributes of the parent bucket. A concrete example would
be:
{code:java}
json.facet={
subject_level_0: {
type: terms,
field: subject_f,
facet: {
subject_level_1: {
type: terms,
prefix: $parent,
field: subject_f,
limit: 5
}
}
}
}
{code}
Note that "$parent" for the "prefix" attribute of the subfacet is _not_
supported syntax, but is intended to denote the value of the term in the parent
bucket. The idea is to support hierarchical browsing over fields whose values
are hierarchical in nature (e.g., "United States", "United States--History",
"United States--History--1783-1815", etc.).
So "$parent" is not supported syntax, but this plugin architecture would make
it possible to create a subclass of {{FacetFieldParser}} whose {{parse()}}
method would return a subclass of {{FacetField}} whose
{{createFacetProcessor(FacetContext fcontext)}} method could parse the parent
bucket value out of the {{FacetContext.filter}} and return a {{FacetProcessor}}
with a contextually-determined prefix ... or something like that.
More generally though, I could imagine wanting to do other types of dynamic
(parameterized and/or contextual) facet configuration, some to support very
specialized use cases, that would be much more straightforwardly and
sustainably implemented with this type of plugin architecture.
> Facet parser plugin for json.facet aka custom facet types
> ---------------------------------------------------------
>
> Key: SOLR-12922
> URL: https://issues.apache.org/jira/browse/SOLR-12922
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
> Reporter: Mikhail Khludnev
> Priority: Minor
> Attachments: SOLR-12922.patch, SOLR-12922.patch
>
>
> Why don't introduce a plugin for json facet parsers? Attaching draft patch,
> it just demonstrate the thing. Test fails, iirc. Opinions?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
