Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 38887 invoked from network); 22 Mar 2010 16:27:52 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 22 Mar 2010 16:27:52 -0000 Received: (qmail 3433 invoked by uid 500); 22 Mar 2010 16:27:50 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 3359 invoked by uid 500); 22 Mar 2010 16:27:50 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 3284 invoked by uid 99); 22 Mar 2010 16:27:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Mar 2010 16:27:50 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Mar 2010 16:27:48 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 54DEB234C48C for ; Mon, 22 Mar 2010 16:27:27 +0000 (UTC) Message-ID: <1398468099.406121269275247346.JavaMail.jira@brutus.apache.org> Date: Mon, 22 Mar 2010 16:27:27 +0000 (UTC) From: "Shai Erera (JIRA)" To: java-dev@lucene.apache.org Subject: [jira] Commented: (LUCENE-2331) Add NoOpMergePolicy In-Reply-To: <1792934797.342041268921427153.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/LUCENE-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848192#action_12848192 ] Shai Erera commented on LUCENE-2331: ------------------------------------ I think it's correct. The idea is to say that even w/ NMP, if you use NMS you ensure that no MS code is ever run (e.g. if you use NMP only, then CMS code [default] will always run but won't do anything). > 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, 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-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org