[ https://issues.apache.org/jira/browse/SOLR-10132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886319#comment-15886319 ]
Christine Poerschke commented on SOLR-10132: -------------------------------------------- re: {{null}} vs. {{SimpleFacets.MATCH_ALL_TERMS}} - SOLR-9914 refactored the "contains" check which was a null or non-null String into a null or non-null SubstringBytesRefFilter object _and_ that change isn't yet part of an official release. On that basis, yes, I think MATCH_ALL_TERMS instead of null would make sense. And for clarity, could I suggest making that change separately from the {{facet.matches}} feature addition here - 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 > > > 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.3.15#6346) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org