When using group.main=true, the results are not mixed as you expect: "If true, the result of the last field grouping command is used as the main result list in the response, using group.format=simple”
https://wiki.apache.org/solr/FieldCollapsing Jim On 1/27/15, 9:22 AM, "Ryan Josal" <rjo...@gmail.com> wrote: >Thanks a lot! I'll try this out later this morning. If group.func and >group.field don't combine the way I think they might, I'll try to look for >a way to put it all in group.func. > >On Tuesday, January 27, 2015, Jim.Musil <jim.mu...@target.com> wrote: > >> 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 <javascript:;>> 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(qu >>>er >> >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.getVal >>>ue >> >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.FunctionFirstPassGroupingColl >>>ec >> >tor.setNextReader(FunctionFirstPassGroupingCollector.java:82)\n\tat >> >>>org.apache.lucene.search.MultiCollector.setNextReader(MultiCollector.jav >>>a: >> >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(Search >>>Ha >> >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 >> >>
