On the one hand, I don't like that the TermsQuery might encourage data modeling that requires to build queries over thousands of terms. On the other hand I think it has become more reasonable recently and tries to do the right thing given the terms it has been created with: - it rewrites to a disjunction when there are few terms - it uses a compressed bit set if it merges sparse postings lists
So I'm +1 on moving it to lucene/core. At the same time, maybe it would make sense to move DocValuesRangeQuery and DocValuesTermsQuery to from lucene/core to lucene/queries? Even if two-phase support made them better it's still a bit scary to have queries whose approximations match all documents? On Thu, May 21, 2015 at 11:00 PM, [email protected] <[email protected]> wrote: > Today I noticed org.apache.lucene.search.join.TermsQuery (package access) in > the join module that is functionally equivalent to one by the same name in > the queries module. It may be a bit historical since the one in the queries > module until recently was a Filter, not a Query. But now there is > redundancy. Based on recent changes in Lucene 5.2 done by Adrien to > TermsQuery; I suspect both implementations would perform about the same. > Thus, I think the one in the ‘join’ module should be deleted. > > Note the ‘join’ module does not yet depends on the ‘queries’ module. I think > the TermsQuery is of such broad general utility that it should go into > Lucene core. > > ~ David -- Adrien --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
