Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-3310

FuzzyAttribute ignores min similarity when generating at hashcode(), toString() and equals() methods

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Won't Fix
    • 2.9, 2.9.1, 2.9.2, 2.9.3, 2.9.4, 3.0, 3.0.1, 3.0.2, 3.0.3, 3.1, 3.2, 3.3
    • None
    • modules/queryparser
    • None
    • New

    Description

      FuzzyAttribute ignores min similarity when generating at hashcode(), toString() and equals() methods

      Attachments

        Activity

          Note that in trunk (4.0) the flexible QueryParser has moved away from using Attributes for configuration.

          Hmm, also: why do these Attr impls implement hashCode/equals? It seems dangerous for attrs in general to claim to implement equals/hashCode since they are mutable state by design...

          mikemccand Michael McCandless added a comment - Note that in trunk (4.0) the flexible QueryParser has moved away from using Attributes for configuration. Hmm, also: why do these Attr impls implement hashCode/equals? It seems dangerous for attrs in general to claim to implement equals/hashCode since they are mutable state by design...

          Good point Michael! At least they shouldn't use mutable values in their hashcode. The only reason I remember to implement hashcode in qp attributes was because Lucene attributes (CharTermAttributeImpl, OffsetAttributeImpl etc) do the same.

          It sounds like all attribute impls shouldn't be doing that and we should fix. Luckily, today, nowhere in Lucene code we use Attribute instances as key or in sets, that is why we probably never hit any problems. However, users may be hitting problems because of that. I think we should fix it as soon as possible as it seems very critical.

          Please, let me know if I am missing something.

          adriano_crestani Adriano Crestani added a comment - Good point Michael! At least they shouldn't use mutable values in their hashcode. The only reason I remember to implement hashcode in qp attributes was because Lucene attributes (CharTermAttributeImpl, OffsetAttributeImpl etc) do the same. It sounds like all attribute impls shouldn't be doing that and we should fix. Luckily, today, nowhere in Lucene code we use Attribute instances as key or in sets, that is why we probably never hit any problems. However, users may be hitting problems because of that. I think we should fix it as soon as possible as it seems very critical. Please, let me know if I am missing something.
          uschindler Uwe Schindler added a comment -

          Initially equals and hashcode in AttributeImpl were abstract and therefore required. I removed that requirement in 3.1 as its useless and unneeded in Lucene.

          I have no idea what the reason behind this was, maybe Michael Busch knows.

          In Lucene 3.x we still have equals and hashcode implemented for most internal attributes for backwards compatibility, in trunk i already removed them mostly (I think).

          uschindler Uwe Schindler added a comment - Initially equals and hashcode in AttributeImpl were abstract and therefore required. I removed that requirement in 3.1 as its useless and unneeded in Lucene. I have no idea what the reason behind this was, maybe Michael Busch knows. In Lucene 3.x we still have equals and hashcode implemented for most internal attributes for backwards compatibility, in trunk i already removed them mostly (I think).
          adriano_crestani Adriano Crestani added a comment - I can still see hashcode method in https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/src/java/org/apache/lucene/analysis/tokenattributes/CharTermAttributeImpl.java
          uschindler Uwe Schindler added a comment -

          New attributes have no longer one. At least its no longer required. I dont know if I had really time to remove them all.

          uschindler Uwe Schindler added a comment - New attributes have no longer one. At least its no longer required. I dont know if I had really time to remove them all.

          I see. So, just to make sure I got it correctly, from 4.0 no Attribute impl should implement hashcode, is that correct?!

          Anyway, I will close this issue, since there is no fix required here.

          adriano_crestani Adriano Crestani added a comment - I see. So, just to make sure I got it correctly, from 4.0 no Attribute impl should implement hashcode, is that correct?! Anyway, I will close this issue, since there is no fix required here.
          uschindler Uwe Schindler added a comment -

          Yes, look e.g. into o.a.l.search.BoostAttributeImpl, there is not hashCode and equals anymore.

          uschindler Uwe Schindler added a comment - Yes, look e.g. into o.a.l.search.BoostAttributeImpl, there is not hashCode and equals anymore.
          tomoko Tomoko Uchida added a comment -

          This issue was moved to GitHub issue: #4383.

          tomoko Tomoko Uchida added a comment - This issue was moved to GitHub issue: #4383 .

          People

            Unassigned Unassigned
            phillipe.ramalho Phillipe Ramalho
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: