Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 16 Oct 2012 22:39:03 +0000 (UTC)
From: "Michael McCandless (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <226989159.54364.1350427143517.JavaMail.jiratomcat@arcas>
In-Reply-To: <967504482.19864.1349878022933.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (LUCENE-4472) Add setting that prevents merging
 on updateDocument
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477418#comment-13477418 ] 

Michael McCandless commented on LUCENE-4472:
--------------------------------------------

I think forced merges or forcing reclaiming of deletions, both invoked
by explicit app request, are very different use cases than the
"natural merging" Lucene does during indexing (not directly invoked by
the app, but as a side effect of other API calls).

So I think it makes sense that the MP has separate methods to handle
these very different use cases.

I don't thing we should use single param / single method XXXContext
approach to "bypass" back compat.  We already tried this with
ScorerContext but backed it out because of the loss of type
safety... for expert APIs like this one I think it's actually good to
require apps to revisit their impls on upgrading, if we've added
parameters: it gives them a chance to improve their impls.  Plus this
API is already marked @experimental...

Also, single method taking a single XXXContext obj means that method
will have to have a switch or bunch of if statements to handle what
are in fact very different use cases, which is rather awkward.

Still, separately I would love to make forceMerge/Deletes un-public so
you have to work harder to invoke them (eg maybe you invoke the merge
policy directly and then call IW.maybeMerge ... or something).  We can
do that separately...

                
> Add setting that prevents merging on updateDocument
> ---------------------------------------------------
>
>                 Key: LUCENE-4472
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4472
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: core/index
>    Affects Versions: 4.0
>            Reporter: Simon Willnauer
>             Fix For: 4.1, 5.0
>
>         Attachments: LUCENE-4472.patch, LUCENE-4472.patch
>
>
> Currently we always call maybeMerge if a segment was flushed after updateDocument. Some apps and in particular ElasticSearch uses some hacky workarounds to disable that ie for merge throttling. It should be easier to enable this kind of behavior. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org