[
https://issues.apache.org/jira/browse/LUCENE-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14804519#comment-14804519
]
David Smiley commented on LUCENE-6305:
--------------------------------------
bq. I wasn't following the interconnection between all of these issues very
closely, but i thought Adrien mentioned at one point that one of the
motivations/ benefits of the FooQuery.Builder APIs (and making the queries
immutable) was that it would allow us to simplify (and make more efficient)
some of the methods like .equals and .hashCode by moving the expensive logic
(ie: deterministically ordering the clauses) into the Builder.build() methods
so that the queries themselves wouldn't have to carry around the extra data
structures or do any particularly complex logic in .equals()
bq. wouldn't that be the best of both worlds? only do the expensive comparisons
/ deterministic ordering of the BooleanClauses once in BooleanQuery.build(),
and for "expert" cases where you are programatically creating adding clauses in
a known deterministic order anyway, you can write you're own custom
BooleanQuery.Builder (sub)class?
+1 Sounds great to me -- best of both worlds indeed.
> BooleanQuery.equals should ignore clause order
> ----------------------------------------------
>
> Key: LUCENE-6305
> URL: https://issues.apache.org/jira/browse/LUCENE-6305
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Attachments: LUCENE-6305.patch, LUCENE-6305.patch
>
>
> BooleanQuery.equals is sensitive to the order in which clauses have been
> added. So for instance "+A +B" would be considered different from "+B +A"
> although it generates the same matches and scores.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
