Solr
  1. Solr
  2. SOLR-2829

Filter queries have false-positive matches. Exposed by user's list titled "Regarding geodist and multiple location fields"

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.4, 4.0-ALPHA
    • Fix Version/s: 3.5, 4.0-ALPHA
    • Component/s: search
    • Labels:
      None
    • Environment:

      N/A

      Description

      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.

      1. SOLR-2829.patch
        11 kB
        Erick Erickson
      2. SOLR-2829.patch
        11 kB
        Erick Erickson
      3. SOLR-2829.patch
        15 kB
        Erick Erickson
      4. SOLR-2829.patch
        4 kB
        Hoss Man
      5. SOLR-2829.patch
        3 kB
        Hoss Man
      6. SOLR-2829.patch
        2 kB
        Emmanuel Espina
      7. SOLR-2829-3x.patch
        16 kB
        Erick Erickson

        Activity

          People

          • Assignee:
            Erick Erickson
            Reporter:
            Erick Erickson
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development