[
https://issues.apache.org/jira/browse/LUCENE-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058170#comment-13058170
]
Robert Muir commented on LUCENE-3271:
-------------------------------------
Thanks for working to clean this up! a few of my comments:
{quote}
similar.* -> suggest module
{quote}
Seems a little funky? I guess if we had a query-expansion module, I would think
it belonged there.
{quote}
FieldCacheRewriteMethod -> This doesn't belong in this contrib or the queries
module. I think we should push it to contrib/misc for the time being. It seems
to have quite a few constraints on when its useful. If indeed
CONSTANT_SCORE_AUTO rewrite is better, then I dont see a purpose for it.
{quote}
My vote would actually be to move this to src/test! :) Yeah there are some
scenarios where this thing could be faster, but really I thought it was just a
good way to add seek to the doctermsindex termsenum. I do think it and its test
would be a nice addition to src/test, if someone wants to use it the can always
snag it from there... its that expert.
{quote}
FuzzyLikeThisQuery -> suggest module. This class seems a mess with its
Similarity hardcoded. With all that said, it does seem to do what it claims and
with some cleanup, it could be good.
{quote}
I actually made some comments about this query in the flexscoring branch:
http://svn.apache.org/repos/asf/lucene/dev/branches/flexscoring/lucene/contrib/queries/src/java/org/apache/lucene/search/FuzzyLikeThisQuery.java
In my opinion, as a rewrite method (i think it would require 2, one for the
variant that ignores TF), we could get better performance out of this with
cleaner code... in other words you would just use ordinary FuzzyQuery and set
this rewrite method for its scoring heuristic, or a BQ of FuzzyQueries if you
are doing the expansion thing
{quote}
SlowCollated* -> They can stay in the module till we have a better place to
nuke them.
{quote}
This is all totally deprecated code that seems nice in contrib to reflect the
fact that its not scalable... I don't think its a huge issue where it goes due
to the fact its deprecate and the name :)
Finally, I wanted to say that its my opinion that we shouldn't put garbage in
modules. Modules should be treated like core I think.... yet at the same time I
totally support efforts to cleanup contrib, either removing sandy stuff or
refactoring it where it belongs in a module.
One option could to create a sandbox directory either under lucene (it contains
src/java and src/test but is totally an unorganized sandbox), or itself as a
contrib temporarily (contrib/sandbox) and take a look at contrib and move stuff
thats good into modules, but toss all the 'odd things' into this sandbox.
> Move 'good' contrib/queries classes to Queries module
> -----------------------------------------------------
>
> Key: LUCENE-3271
> URL: https://issues.apache.org/jira/browse/LUCENE-3271
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Chris Male
>
> With the Queries module now filled with the FunctionQuery stuff, we should
> look at closing down contrib/queries. While not a huge contrib, it contains
> a number of pretty useful classes and some that should go elsewhere.
> Heres my proposed plan:
> - similar.* -> suggest module
> - regex.* -> queries module
> - BooleanFilter -> queries module under .filters package
> - BoostingQuery -> queries module
> - ChainedFilter -> queries module under .filters package
> - DuplicateFilter -> queries module under .filters package
> - FieldCacheRewriteMethod -> This doesn't belong in this contrib or the
> queries module. I think we should push it to contrib/misc for the time
> being. It seems to have quite a few constraints on when its useful. If
> indeed CONSTANT_SCORE_AUTO rewrite is better, then I dont see a purpose for
> it.
> - FilterClause -> class inside BooleanFilter
> - FuzzyLikeThisQuery -> suggest module. This class seems a mess with its
> Similarity hardcoded. With all that said, it does seem to do what it claims
> and with some cleanup, it could be good.
> - TermsFilter -> queries module under .filters package
> - SlowCollated* -> They can stay in the module till we have a better place to
> nuke them.
> One of the implications of the above moves, is that the xml-query-parser,
> which supports many of the queries, will need to have a dependency on the
> queries module. But that seems unavoidable at this stage.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
