I¹m not sure the query you provided will do what you want, BUT I did find
the bug in the code that is causing the NullPointerException.
The variable context is supposed to be global, but when prepare() is
called, it is only defined in the scope of that function.
Here¹s the simple patch:
Index: core/src/java/org/apache/solr/search/Grouping.java
===================================================================
--- core/src/java/org/apache/solr/search/Grouping.java (revision 1653358)
+++ core/src/java/org/apache/solr/search/Grouping.java (working copy)
@@ -926,7 +926,7 @@
*/
@Override
protected void prepare() throws IOException {
- Map context = ValueSource.newContext(searcher);
+ context = ValueSource.newContext(searcher);
groupBy.createWeight(context, searcher);
actualGroupsToFind = getMax(offset, numGroups, maxDoc);
}
I¹ll search for a Jira issue and open if I can¹t find one.
Jim Musil
On 1/26/15, 6:34 PM, "Ryan Josal" <r...@josal.com> wrote:
>I have an index of products, and these products have a "category" which we
>can say for now is a good approximation of its location in the store. I'm
>investigating altering the ordering of the results so that the categories
>aren't interlaced as much... so that the results are a little bit more
>grouped by category, but not *totally* grouped by category. It's
>interesting because it's an approach that sort of compares results to
>near-scored/ranked results. One of the hoped outcomes of this would that
>there would be somewhat fewer categories represented in the top results
>for
>a given query, although it is questionable if this is a good measurement
>to
>determine the effectiveness of the implementation.
>
>My first attempt was to
>group=true&group.main=true&group.field=category&group.func=rint(scale(quer
>y({!type=edismax
>v=$q}),0,20))
>
>Or some FunctionQuery like that, so that in order to become a member of a
>group, the doc would have to have the same category, and be dropped into
>the same score bucket (20 in this case). This doesn't work out of the
>gate
>due to an NPE (solr 4.10.2) (although I'm not sure it would work anyway):
>
>java.lang.NullPointerException\n\tat
>org.apache.lucene.queries.function.valuesource.ScaleFloatFunction.getValue
>s(ScaleFloatFunction.java:104)\n\tat
>org.apache.solr.search.DoubleParser$Function.getValues(ValueSourceParser.j
>ava:1111)\n\tat
>org.apache.lucene.search.grouping.function.FunctionFirstPassGroupingCollec
>tor.setNextReader(FunctionFirstPassGroupingCollector.java:82)\n\tat
>org.apache.lucene.search.MultiCollector.setNextReader(MultiCollector.java:
>113)\n\tat
>org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:612)\n\ta
>t
>org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:297)\n\ta
>t
>org.apache.solr.search.Grouping.searchWithTimeLimiter(Grouping.java:451)\n
>\tat
>org.apache.solr.search.Grouping.execute(Grouping.java:368)\n\tat
>org.apache.solr.handler.component.QueryComponent.process(QueryComponent.ja
>va:459)\n\tat
>org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHa
>ndler.java:218)\n\tat
>
>
>Has anyone tried something like this before, and does anyone have any
>novel
>ideas for how to approach it, no matter how different? How about a
>workaround for the group.func error here? I'm very open-minded about
>where
>to go on this one.
>
>Thanks,
>Ryan
