[
https://issues.apache.org/jira/browse/LUCENE-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848158#action_12848158
]
Michael McCandless commented on LUCENE-2331:
--------------------------------------------
bq. You ask because of the useCompound* methods?
Yes, because these methods (unexpectedly -- not good) also affect whether newly
flushed segments are CFS or not.
I think just the two is OK? One can always make their own class if they really
need diff't settings for the stores vs non-stores.
> Add NoOpMergePolicy
> -------------------
>
> Key: LUCENE-2331
> URL: https://issues.apache.org/jira/browse/LUCENE-2331
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Index
> Reporter: Shai Erera
> Assignee: Michael McCandless
> Fix For: 3.1
>
> Attachments: LUCENE-2331.patch, LUCENE-2331.patch
>
>
> I'd like to add a simple and useful MP implementation which does .... nothing
> ! :). I've came across many places where either the following is documented
> or implemented: "if you want to prevent merges, set mergeFactor to a high
> enough value". I think a NoOpMergePolicy is just as good, and can REALLY
> allow you disable merges (except for maybe set mergeFactor to Int.MAX_VAL).
> As such, NoOpMergePolicy will be introduced as a singleton, and can be used
> for convenience purposes only. Also, for Parallel Index it's important,
> because I'd like the slices to never do any merges, unless ParallelWriter
> decides so. So they should be set w/ that MP.
> I have a patch ready. Waiting for LUCENE-2320 to go in, so that I don't need
> to change it afterwards.
> About the name - I like the name, but suggestions are welcome. I thought of a
> NullMergePolicy, but I don't like 'Null' used for a NoOp.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
