How should I proceed with this problem? Should I create a JIRA issue or should I cross-post on the dev mailing list? Any suggestions?
Cheers, Thomas On Wed, Jul 6, 2011 at 9:49 AM, Thomas Heigl <tho...@umschalt.com> wrote: > My query in the unit test looks like this: > > q=*:*&fq=_query_:"{!geofilt sfield=user.location_p pt=48.20927,16.3728 >> d=50.0}" OR _query_:"{!geofilt sfield=location_p pt=48.20927,16.3728 >> d=50.0}"&group=true&group.main=true&group.format=grouped&group.field=user.uniqueId_s&sfield=user.location_p&pt=48.20927,16.3728&sort=geodist() >> asc > > > This works without a problem in my trunk build of Solr 4.0 from March 2011. > I use the standard schema.xml packaged with the Solr distribution. > > Thomas > > On Tue, Jul 5, 2011 at 10:20 AM, Thomas Heigl <tho...@umschalt.com> wrote: > >> I'm pretty sure my original query contained a distance filter as well. Do >> I absolutely need to filter by distance in order to sort my results by it? >> >> I'll write another unit test including a distance filter as soon as I get >> a chance. >> >> Cheers, >> >> Thomas >> >> >> On Tue, Jul 5, 2011 at 9:04 AM, Bill Bell <billnb...@gmail.com> wrote: >> >>> Did you add: fq={!geofilt} ?? >>> >>> On 7/3/11 11:14 AM, "Thomas Heigl" <tho...@umschalt.com> wrote: >>> >>> >Hello, >>> > >>> >I just tried up(down?)grading our current Solr 4.0 trunk setup to Solr >>> >3.3.0 >>> >as result grouping was the only reason for us to stay with the trunk. >>> >Everything worked like a charm except for one of our queries, where we >>> >group >>> >results by the owning user and sort by distance. >>> > >>> >A simplified example for my query (that still fails) looks like this: >>> > >>> >>> >q=*:*&group=true&group.field=user.uniqueId_s&group.main=true&group.format= >>> >grouped&sfield=user.location_p&pt=48.20927,16.3728&sort=geodist() >>> >> asc >>> > >>> > >>> >The exception thrown is: >>> > >>> >Caused by: org.apache.solr.common.SolrException: Unweighted use of sort >>> >> geodist(latlon(user.location_p),48.20927,16.3728) >>> >> at >>> >> >>> >>> >>org.apache.solr.search.function.ValueSource$1.newComparator(ValueSource.j >>> >>ava:106) >>> >> at >>> org.apache.lucene.search.SortField.getComparator(SortField.java:413) >>> >> at >>> >> >>> >>> >>org.apache.lucene.search.grouping.AbstractFirstPassGroupingCollector.<ini >>> >>t>(AbstractFirstPassGroupingCollector.java:81) >>> >> at >>> >> >>> >>> >>org.apache.lucene.search.grouping.TermFirstPassGroupingCollector.<init>(T >>> >>ermFirstPassGroupingCollector.java:56) >>> >> at >>> >> >>> >>> >>org.apache.solr.search.Grouping$CommandField.createFirstPassCollector(Gro >>> >>uping.java:587) >>> >> at org.apache.solr.search.Grouping.execute(Grouping.java:256) >>> >> at >>> >> >>> >>> >>org.apache.solr.handler.component.QueryComponent.process(QueryComponent.j >>> >>ava:237) >>> >> at >>> >> >>> >>> >>org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchH >>> >>andler.java:194) >>> >> at >>> >> >>> >>> >>org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBa >>> >>se.java:129) >>> >> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1368) >>> >> at >>> >> >>> >>> >>org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(Embedded >>> >>SolrServer.java:140) >>> >> ... 39 more >>> > >>> > >>> >Any ideas how to fix this or work around this error for now? I'd really >>> >like >>> >to move from the trunk to the stable 3.3.0 release and this is the only >>> >problem currently keeping me from doing so. >>> > >>> >Cheers, >>> > >>> >Thomas >>> >>> >>> >> >