[
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
Proposing revised patch which avoids use of {{Predicate<BytesRef> MATCH_ALL =
input -> true;}} because e.g. in
[DocValuesFacets.java#L187-L192|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/request/DocValuesFacets.java#L187-L192]
the predicate is used like this
{code}
if (termFilter != null) {
final BytesRef term = si.lookupOrd(startTermIndex+i);
if (!termFilter.test(term)) {
continue;
}
}
{code}
and a non-null {{MATCH_ALL}} predicate would thus incur the {{si.lookupOrd}}
call cost only to then arrive at the 'yes it matches' answer. What do you think?
----
proposed next steps:
* SOLR-10155 to go ahead first, then here rebase patch on top of it
* {{SimpleFacetsTest.testSimpleFacetCounts}} is already very long i.e.
[SimpleFacetsTest.java#L540-L783|https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L540-L783]
- how about having a separate test for the new parameter logic e.g. similar to
the testFacetExclude and testFacetContainsAndExclude methods added in SOLR-9912
* check javadocs and that {{ant precommit}} passes
> 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: [email protected]
For additional commands, e-mail: [email protected]
