[
https://issues.apache.org/jira/browse/LUCENE-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145646#comment-13145646
]
Michael McCandless commented on LUCENE-3454:
--------------------------------------------
bq. I could set MP in such a way that forceMerge(1) would still do nothing.
That's very simple in fact, and I do this today.
Sure, but remember: 1) this is the exception case (not the rule), and
2) you are an expert user.
We should name our APIs according to what they "typically" do, not by
the exceptional cases, which can and should be handled by javadocs
(for example, that you must close your IW if you hit OOME during
addDocument).
The expert users (like you) who are bumping up against these
exceptions can easily understand and handle them.
I think forceMerge(int) does a pretty good job explaining what the MP
is going to try to do.
bq. I think that the problem is that we try to come up with names that reflect
what API we IndexWriter should call on MP.
Right, optimize() is really sugar for "invoking the current MP and do
whatever it says".
bq. So maybe we should go for a more extreme change – how about having one
method merge() which takes a MergePolicy with a single method
findSegmentsForMerge().
This is a great idea! But I think we should pursue it under a new
issue, after renaming the optimize method? It's a bigger change.
If we took this approach... I think IW would still need a "default MP"
that it uses to kick off natural merges over time? (Ie, after a new
segment is flushed).
Alternatively, we could have this extra MP sit fully "outside" of IW,
and so instead of calling IW.merge(MP) you'd call MP.merge(IW), and
that "foreign" MP would register merges with IW? Still, it's gonna
get tricky, how the "natural" MP interacts with this foreign MP.
Or... maybe we remove IW.optimize, and instead open up a method on
each MP impl (eg MP.forceMerge(int)), and you invoke this method on
the MP instead? This way you still have the one MP, but IW doesn't
need to expose hard-to-name sugar? Still sounds tricky though... the
MP would ask IW to maybeMerge
> rename optimize to a less cool-sounding name
> --------------------------------------------
>
> Key: LUCENE-3454
> URL: https://issues.apache.org/jira/browse/LUCENE-3454
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 3.4, 4.0
> Reporter: Robert Muir
> Assignee: Michael McCandless
> Attachments: LUCENE-3454.patch
>
>
> I think users see the name optimize and feel they must do this, because who
> wants a suboptimal system? but this probably just results in wasted time and
> resources.
> maybe rename to collapseSegments or something?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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
