[jira] [Updated] (SOLR-10132) Support facet.matches to cull facets returned with a regex

2017-10-10 Thread Christine Poerschke (JIRA) 

 [ 
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 (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
> ="/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

[jira] [Updated] (SOLR-10132) Support facet.matches to cull facets returned with a regex

2017-09-18 Thread Gus Heck (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-10132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gus Heck updated SOLR-10132:

Attachment: SOLR-10132.patch

Patch returning null, with separated test, and doc. I'd rather not have the 
newExcludeButesRefFilter, method but unfortunately it is protected access, so 
I'm not sure if it can be eliminated. See comment in patch to this effect.

> 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
>
>
> 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
> ="/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

[jira] [Updated] (SOLR-10132) Support facet.matches to cull facets returned with a regex

2017-02-21 Thread Christine Poerschke (JIRA) 

 [ 
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 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
> ="/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

[jira] [Updated] (SOLR-10132) Support facet.matches to cull facets returned with a regex

2017-02-17 Thread Gus Heck (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-10132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gus Heck updated SOLR-10132:

Attachment: SOLR-10132.patch

revised patch with inheritance from SubstringBytesRefFilter

> 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
> Attachments: 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
> ="/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

[jira] [Updated] (SOLR-10132) Support facet.matches to cull facets returned with a regex

2017-02-13 Thread Gus Heck (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-10132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gus Heck updated SOLR-10132:

Attachment: SOLR-10132.patch

Initial patch with some tests, but not ready since I still need to figure out 
what to do with the check for numeric facets (see question in comment patch).

> 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
> Attachments: 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
> ="/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