[
https://issues.apache.org/jira/browse/LUCENE-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14001038#comment-14001038
]
Shai Erera commented on LUCENE-5672:
------------------------------------
IIRC, I changed that on LUCENE-2245. The core motivation was to keep the
addIndexes versions doing the minimal work that's required for them to function
properly. So the Directory version merely copies the files over to the target
index and the Reader version migrates them to the target index. Other than
that, we should let the MP workout the best merges to execute etc.
This lets the caller decide how expensive should addIndexes be, on his part.
You can freely call forceMerge/maybeMerge before/after addIndexes, or not
execute merges at all. I found this beneficial e.g. when creating indexes via
MapReduce, where I used addIndexes, but wanted to wait with merges until the
end. When addIndexes always calls maybeMerge, it means it always does this
work, and the only way to avoid that is use NoMergePolicy. Perhaps NoMP came
after the addIndexes cleanup, not sure...
I like it that addIndexes does the minimum work that's needed. Can you
elaborate why is this buggy? What prevents the app from invoking merges itself?
I mean, this is not like addDocument() calls ... I believe that addIndexes are
less common, and more ... expert?
> Addindexes does not call maybeMerge
> -----------------------------------
>
> Key: LUCENE-5672
> URL: https://issues.apache.org/jira/browse/LUCENE-5672
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> I don't know why this was removed, but this is buggy and just asking for
> trouble.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
