Lucene - Core
  1. Lucene - Core
  2. LUCENE-3310

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

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 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
    • Fix Version/s: None
    • Component/s: modules/queryparser
    • Labels:
      None
    • Lucene Fields:
      New

      Description

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

        Activity

        Phillipe Ramalho created issue -
        Hide
        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...

        Show
        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...
        Hide
        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.

        Show
        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.
        Hide
        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).

        Show
        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).
        Show
        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
        Hide
        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.

        Show
        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.
        Hide
        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.

        Show
        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.
        Adriano Crestani made changes -
        Field Original Value New Value
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Won't Fix [ 2 ]
        Hide
        Uwe Schindler added a comment -

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

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

          People

          • Assignee:
            Unassigned
            Reporter:
            Phillipe Ramalho
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development