[
http://issues.apache.org/jira/browse/LUCENE-460?page=comments#action_12356414 ]
Yonik Seeley commented on LUCENE-460:
-------------------------------------
Paul, I'm not sure I understand your point about "structure information added
by the query parser is lost in the hash".
Let me rephrase my statement in case you misunderstood me:
- hash codes should strive to avoid collisions across Query hierarchy, not
just within one specific
subclass. An example of hashCode implementations that don't do this are
TermQuery(t) and SpanTermQuery(t) which will generate the exact same hash
codes.
> What's the point of hash code uniqueness over subclasses?
The same point as hash code uniqueness (avoiding collisions) within a
particular class - the more collisions you have, the more it will slow down
hash based lookups. Things should still work if all hashCodes mapped to the
same number, but it would be dog slow.
> hashCode improvements
> ---------------------
>
> Key: LUCENE-460
> URL: http://issues.apache.org/jira/browse/LUCENE-460
> Project: Lucene - Java
> Type: Improvement
> Components: Search
> Versions: CVS Nightly - Specify date in submission
> Reporter: Yonik Seeley
> Priority: Minor
> Fix For: CVS Nightly - Specify date in submission
>
> It would be nice for all Query classes to implement hashCode and equals to
> enable them to be used as keys when caching.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
