lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-2829) Filter queries have false-positive matches. Exposed by user's list titled "Regarding geodist and multiple location fields"
Date Wed, 02 Nov 2011 00:17:33 GMT


Yonik Seeley commented on SOLR-2829:

bq. I don't really understand yonik's comment at all

the equals() method in question includes the following:
&& this.lonSource.equals(other.lonSource)
&& this.latSource.equals(other.latSource)

latSource and lonSource are ValueSources derived from the field.  They should not compare
equal when derived from a different field.  Hence there is a value source / function query
issue here somewhere (the real bug).
> Filter queries have false-positive matches. Exposed by user's list titled "Regarding
geodist and multiple location fields"
> --------------------------------------------------------------------------------------------------------------------------
>                 Key: SOLR-2829
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>          Components: search
>    Affects Versions: 3.4, 4.0
>         Environment: N/A
>            Reporter: Erick Erickson
>            Priority: Blocker
>             Fix For: 3.5
>         Attachments: SOLR-2829.patch, SOLR-2829.patch
> I don't know how generic this is, whether it's just a
> problem with fqs when combined with spatial or whether
> it has wider applicability , but here's what I know so far.
> Marc Tinnemeyer in a post titled:
> "Regarding geodist and multiple location fields"
> outlines this. I checked this on 3.4 and trunk and it's
> weird in both cases.
> After looking at this a bit more, it looks like a caching
> issue, NOT a geodist issue. When I bounce Solr
> between changing the sfield from "home" to "work",
> it seems to work as expected.
> Hmmmm, very strange. If I comment out BOTH
> the filterCache and queryResultCache then it works
> fine. Switching from "home" to "work" in the query
> finds/fails to find the document.
> But commenting out only one of those caches
> doesn't fix the problem.
> on trunk I used this query; just flipping "home" to "work" and back:
> http://localhost:8983/solr/select?q=id:1&fq={!geofilt sfield=home
> pt=52.67,7.30 d=5}
> The info below is what I used to test.
> From Marc's posts:
> <field name="home" type="location" indexed="true" stored="true"/>
> <field name="work" type="location" indexed="true" stored="true"/>
> <field name="elsewhere" type="location" indexed="true" stored="true"/>
> At first I thought so too. Here is a simple document.
> <add>
>       <doc>
>               <field name="id">1</field>
>               <field name="name">first</field>
>               <field name="work">48.60,11.61</field>
>               <field name="home">52.67,7.30</field>
>       </doc>
> </add>
> and here is the result that shouldn't be:
> <response>
> ...
> <str name="q">*:*</str>
> <str name="fq">{!geofilt sfield=work pt=52.67,7.30 d=5}</str>
> ...
> </lst>
> </lst>
> <result name="response" numFound="1" start="0">
> <doc>
> <str name="home">52.67,7.30</str>
> <str name="id">1</str>
> <str name="name">first</str>
> <str name="work">48.60,11.61</str>
> </doc>
> </result>
> </response>
> ****Yonik's comment******
> It's going to be a bug in an equals() implementation somewhere in the query.
> The top level equals will be SpatialDistanceQuery.equals() (from
> On trunk, I already see a bug introduced when the new lucene field
> cache stuff was done.
> DoubleValueSource now just inherits it's equals method from
> NumericFieldCacheSource... and that equals() method only tests if the
> CachedArrayCreator.getClass() is the same!  That's definitely wrong.
> I don't know why 3x would also have this behavior (unless there's more
> than one bug!)
> Anyway, first step is to modify the spatial tests to catch the bug...
> from there it should be pretty easy to debug.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message