[
https://issues.apache.org/jira/browse/LUCENE-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146992#comment-13146992
]
Shai Erera commented on LUCENE-3569:
------------------------------------
What instanceof are you talking about? There won't be "just one" MP for
optimizing, or regular merges or whatever cleanup. We will provide OOtB MPs for
different tasks, default to a one that makes sense for regular merges, and let
the user call merge()/doMaintenance()/pickYouFavoriteName() whenever he wants,
but we'll tell him to pass an MP for that.
What's wrong with that? Why our methods can take a maxNumSegments and not
timeLimitForMerge or whatever criteria that determines when to stop? Instead of
coding that into the method signature, we allow users to pass MPs that they
want.
I really think that you're fooling yourself if you think that forceMerge() is
more intimidating than merge(TotalSegmentsMergePolicy) or something. Do you
really believe our users are that stupid that they don't read javadocs at all !?
> Consolidate IndexWriter's optimize, maybeMerge and expungeDeletes under one
> merge(MP) method
> --------------------------------------------------------------------------------------------
>
> Key: LUCENE-3569
> URL: https://issues.apache.org/jira/browse/LUCENE-3569
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/index
> Reporter: Shai Erera
>
> Today, IndexWriter exposes 3 methods for 'cleaning up' / 'compacting' /
> 'optimizing' your index:
> * optimize() -- merges as much segments as possible (down to 1 segment), and
> is discouraged in many cases because of its performance implications.
> * maybeMerge() -- runs 'subtle' merges. Attempts to balance the index by not
> leaving too many segments, yet not merging large segments if unneeded.
> * expungeDeletes() -- cleans up deleted documents from segments and on the go
> merges them.
> * a default MP that can be set on IndexWriterConfig, for ongoing merges IW
> performs (i.e. as a result of flushing a new segment).
> These methods are confusing in several levels:
> * Their names are misleading, see LUCENE-3454.
> * Why does expungeDeletes need to merge segments?
> * Eventually, they really do what the MergePolicy decides that should be
> done. I.e., one could write an MP that always merges all segments, and
> therefore calling maybeMerge would not be so subtle anymore. On the other
> hand, one could write an MP that never merges large segments (we in fact have
> several of those), and therefore calling optimize(1) would not end up with
> one segment.
> So the proposal is to replace all these methods with a single one
> merge(MergePolicy) (more on the names later). MergePolicy will have only one
> method findSegmentsForMerge and the caller will be responsible to configure
> it in order to perform the needed merges. We will provide ready-to-use MPs:
> * LightMergePolicy -- for setting on IWC and doing the ongoing merges IW
> executes. This one will pick segments respecting various parameters such as
> mergeFactor, segmentSizes etc.
> * HeavyMergePolicy -- for doing the optimize()-style merges.
> * ExpungeDeletesMergePolicy -- for expunging deletes (my proposal is to drop
> segment merging from it, by default).
> Now about the names:
> * I think that it will be good, API-backcompat wise and in general, if we
> name that method doMaintenance (as expungeDeletes does not have to merge
> anything).
> * Instead of MergePolicy we call it MaintenancePolicy and similarly its
> single method findSegmentsForMaintenance, or getMaintenanceSpecification.
> * I called the MPs Light and Heavy just for the text, I think a better name
> should be found, but nothing comes up to mind now.
> It will allow us to use this on 3.x, by deprecating MP and all related
> methods.
--
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: [email protected]
For additional commands, e-mail: [email protected]
