[jira] [Comment Edited] (SOLR-12922) Facet parser plugin for json.facet aka custom facet types

["Michael Gibney (JIRA)" <ji...@apache.org>]

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org