On Thu, Nov 21, 2024 at 9:05 AM Mikhail Khludnev <m...@apache.org> wrote:
> Hello > This question is a spin off from > https://github.com/apache/solr/pull/2742/. > PR#2742 <https://github.com/apache/solr/pull/2742/.PR#2742> is about > deploying custom AggValueSource parsers and invoke it via > { > type:func, > func:custom,.. > } > The question is, how user can deploy own facet {type:custom}? see > > https://solr.apache.org/guide/solr/latest/query-guide/json-facet-api.html#types-of-facets > > I see two options: > - introduce a new extension point: FacetParser it's a kind of sibling for > QParserPlugin. My concerns are: There are some boilerplates around it e.g. > support new tag in solrconfig.xml, then support it in Config API, what > else? Then, it's going to be an extension point for the FacetModule > component, which who knows _will be with us forever_ you know. > This is the most straight-forward path, I think. It screams for plug-ability in my eyes when I see that switch statement over the predefined types. - make some surgery over FacetModule to make it subclassable, i.e. a user > creates a subclass of FacetModule overriding parseFacetOrStat() > < > https://github.com/apache/solr/blob/b76a29d17c874806e3b6516810772e2238e93098/solr/core/src/java/org/apache/solr/search/facet/FacetParser.java#L141 > > > and deploy it via existing plugin/module/configAPI. > Note: the first attempt to make FacetModule subclassable was really scary > https://github.com/apache/solr/pull/2865 the problem deserves more > efforts. > I looked at the "really scarry" PR and I wasn't scared at all. The super frequent overriding of parseFacetOrStat looked annoying to me, though. > Which of these paths would you like to pursue? > The first: pluggable FacetParser. If FacetModule is expressly configured in solrconfig.xml (albeit isn't normally I suppose), this would logically be where one would further configure the additional parsers specific for that module. The FacetModule.init() is called which could then do SolrResourceLoader to initialize stuff. I could see making the existing parsers less hard-coded. ~ David
