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
>>>
>>>
>>>
>>
>
