Re: Exception when using result grouping and sorting by geodist() with Solr 3.3
Hi Yonik, I just created a JIRA issue: https://issues.apache.org/jira/browse/SOLR-2642 Thomas On Fri, Jul 8, 2011 at 4:00 PM, Yonik Seeley wrote: > On Fri, Jul 8, 2011 at 4:11 AM, Thomas Heigl wrote: > > 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? > > Yes, this definitely sounds like a bug in the 3.3 grouping (looks like > it forgets to weight the sorts). > Could you open a JIRA issue? > > -Yonik > http://www.lucidimagination.com >
Re: Exception when using result grouping and sorting by geodist() with Solr 3.3
On Fri, Jul 8, 2011 at 4:11 AM, Thomas Heigl wrote: > 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? Yes, this definitely sounds like a bug in the 3.3 grouping (looks like it forgets to weight the sorts). Could you open a JIRA issue? -Yonik http://www.lucidimagination.com
Re: Exception when using result grouping and sorting by geodist() with Solr 3.3
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 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 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 wrote:
>>
>>> Did you add: fq={!geofilt} ??
>>>
>>> On 7/3/11 11:14 AM, "Thomas Heigl" 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.>> >>t>(AbstractFirstPassGroupingCollector.java:81)
>>> >> at
>>> >>
>>>
>>> >>org.apache.lucene.search.grouping.TermFirstPassGroupingCollector.(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
>>>
>>>
>>>
>>
>
Re: Exception when using result grouping and sorting by geodist() with Solr 3.3
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 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 wrote:
>
>> Did you add: fq={!geofilt} ??
>>
>> On 7/3/11 11:14 AM, "Thomas Heigl" 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.> >>t>(AbstractFirstPassGroupingCollector.java:81)
>> >> at
>> >>
>>
>> >>org.apache.lucene.search.grouping.TermFirstPassGroupingCollector.(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
>>
>>
>>
>
Re: Exception when using result grouping and sorting by geodist() with Solr 3.3
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 wrote:
> Did you add: fq={!geofilt} ??
>
> On 7/3/11 11:14 AM, "Thomas Heigl" 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. >>t>(AbstractFirstPassGroupingCollector.java:81)
> >> at
> >>
> >>org.apache.lucene.search.grouping.TermFirstPassGroupingCollector.(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
>
>
>
Re: Exception when using result grouping and sorting by geodist() with Solr 3.3
Did you add: fq={!geofilt} ??
On 7/3/11 11:14 AM, "Thomas Heigl" 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.>t>(AbstractFirstPassGroupingCollector.java:81)
>> at
>>
>>org.apache.lucene.search.grouping.TermFirstPassGroupingCollector.(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
Exception when using result grouping and sorting by geodist() with Solr 3.3
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.java:106) > at org.apache.lucene.search.SortField.getComparator(SortField.java:413) > at > org.apache.lucene.search.grouping.AbstractFirstPassGroupingCollector.(AbstractFirstPassGroupingCollector.java:81) > at > org.apache.lucene.search.grouping.TermFirstPassGroupingCollector.(TermFirstPassGroupingCollector.java:56) > at > org.apache.solr.search.Grouping$CommandField.createFirstPassCollector(Grouping.java:587) > at org.apache.solr.search.Grouping.execute(Grouping.java:256) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:237) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1368) > at > org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.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
