Solr
  1. Solr
  2. SOLR-3548

some queries produced by builtin QParsers do not satisfy QueryUtils checks

    Details

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

      Description

      working on SOLR-3522 i discovered that in some cases Solr is producing queries that aren't equals to themselves, so they can't be cached.

      So far the only observed problem is in func strdist, but i want to make sure we have an exhaustive test of this in case there are others

      1. SOLR-3548.patch
        31 kB
        Hoss Man
      2. SOLR-3548.patch
        26 kB
        Hoss Man
      3. SOLR-3548.patch
        6 kB
        Hoss Man

        Activity

        Hide
        Hoss Man added a comment -

        test case

        Show
        Hoss Man added a comment - test case
        Hide
        Hoss Man added a comment -

        it took a lot longer then i though, but here is a patch that adds QueryUtils checking against (at least one of) the Query objects produced by every default QParser and ValueSourceParser. It includes a future proofing "testCoverage" that sets a bit informing an AfterClass method to assert that all of the default parsers were tested so we don't risk this probably again the next time someone adds a new parsers.

        Currently 4 methods are failing, indicating the following problems...

        • strdist func - identical query strings don't produce equals() queries
        • join qparser - clone w/diff boost still has equals hashCode
        • bbox qparser - clone w/diff boost still has equals hashCode
        • geofilt qparser - clone w/diff boost still has equals hashCode

        the hashCode equality isn't the end of the world, but it suggests a really poor hashCode impl (that evidently doesn't call super since Query.hashCode already handles the boost)

        Show
        Hoss Man added a comment - it took a lot longer then i though, but here is a patch that adds QueryUtils checking against (at least one of) the Query objects produced by every default QParser and ValueSourceParser. It includes a future proofing "testCoverage" that sets a bit informing an AfterClass method to assert that all of the default parsers were tested so we don't risk this probably again the next time someone adds a new parsers. Currently 4 methods are failing, indicating the following problems... strdist func - identical query strings don't produce equals() queries join qparser - clone w/diff boost still has equals hashCode bbox qparser - clone w/diff boost still has equals hashCode geofilt qparser - clone w/diff boost still has equals hashCode the hashCode equality isn't the end of the world, but it suggests a really poor hashCode impl (that evidently doesn't call super since Query.hashCode already handles the boost)
        Hide
        Hoss Man added a comment -

        Fixed JoinQuery and SpatialDistanceQuery classes to consult super.equals() and super.hashCode() in their corrisponding methods, and added completely new equals/hashCode impls to JaroWinklerDistance, NGramDistance, and LevensteinDistance (which never had them before aparently).

        This gets all the new tests passing

        Show
        Hoss Man added a comment - Fixed JoinQuery and SpatialDistanceQuery classes to consult super.equals() and super.hashCode() in their corrisponding methods, and added completely new equals/hashCode impls to JaroWinklerDistance, NGramDistance, and LevensteinDistance (which never had them before aparently). This gets all the new tests passing
        Hide
        Hoss Man added a comment -

        Committed revision 1351839. - trunk
        Committed revision 1351843. - 4x

        Show
        Hoss Man added a comment - Committed revision 1351839. - trunk Committed revision 1351843. - 4x

          People

          • Assignee:
            Hoss Man
            Reporter:
            Hoss Man
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development