Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Wed, 2 Nov 2011 12:05:32 +0000 (UTC)
From: "Erick Erickson (Commented) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <1257209319.50090.1320235532331.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1320241825.9059.1318513091824.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (SOLR-2829) Filter queries have false-positive
 matches. Exposed by user's list titled "Regarding geodist and multiple
 location fields"
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13142080#comment-13142080 ] 

Erick Erickson commented on SOLR-2829:
--------------------------------------

Well, now that others have done the hard part, any objections if I commit it? This seems serious enough it shouldn't get lost in the shuffle. And I'm assuming it should be both a trunk and 3x change, right?

Should I create another JIRA reflecting Hoss's comments today (2-Nov) on cleaning up generally that refers back to this issue while I'm at it?
                
> Filter queries have false-positive matches. Exposed by user's list titled "Regarding geodist and multiple location fields"
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-2829
>                 URL: https://issues.apache.org/jira/browse/SOLR-2829
>             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, 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.
> HOLD THE PRESSES:
> 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
> LatLonField.java)
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org