[
https://issues.apache.org/jira/browse/SOLR-10132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-10132:
---------------------------------------
Attachment: SOLR-10132.patch
Thanks Gus for updating the patch! I today finally returned to this.
Please find attached slightly revised patch with changes as follows:
* RegexBytesRefFilter now no longer extends SubstringBytesRefFilter but just
implements Predicate<BytesRef> (previously extending SubstringBytesRefFilter
was helpful/needed but with SOLR-10155 that changed)
* Added javadocs for newExcludeBytesRefFilter, as you say, they were missing in
the existing code. (in conjunction with SOLR-9800 the method allows for (say) a
custom facet component which uses not excluded terms passed in a parameter but
use of (say) an exclusion list stored in ZooKeeper)
* minor style/format tweaks
* In the {{testFacetMatch}} method the
{code}
new String[]{"", "uif"}
{code}
line puzzled me and it should be
{code}
new String[]{"facet.method", "uif"}
{code}
instead I think.
* In the test there was
{code}
, "*[count(//lst[@name='trait_s']/int)=2]"
, "//lst[@name='trait_s']/int[@name='Tool'][.='2']"
, "//lst[@name='trait_s']/int[@name='Obnoxious'][.='2']"
, "*[count(//lst[@name='trait_s']/int[@name='Pig'])=0]"
{code}
and wasn't sure if the "Pig" line's presence is intended and clear without a
comment, so removed it.
* FacetParams.FACET_MATCH "match" is now FacetParams.FACET_MATCHES "matches"
since the latter was in the .adoc and seems clearer - what do you think?
> Support facet.matches to cull facets returned with a regex
> ----------------------------------------------------------
>
> Key: SOLR-10132
> URL: https://issues.apache.org/jira/browse/SOLR-10132
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: faceting
> Affects Versions: 6.4.1
> Reporter: Gus Heck
> Assignee: Christine Poerschke
> Attachments: SOLR-10132.patch, SOLR-10132.patch, SOLR-10132.patch,
> SOLR-10132.patch, SOLR-10132.patch
>
>
> I recently ran into a case where I really wanted to only return the next
> level of a hierarchical facet, and while I was able to do that with a
> coordinated set of dynamic fields, it occurred to me that this would have
> been much much easier if I could have simply used PathHierarchyTokenizer and
> written
> &facet.matches="/my/current/prefix/[^/]+$"
> thereby limiting the returned facets to the next level down and not return
> the additional N levels I didn't (yet) want to display (numbering in the
> thousands near the top of the tree). I suspect there are other good use
> cases, and the patch seemed relatively tractable.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
