[
https://issues.apache.org/jira/browse/LUCENE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007528#comment-13007528
]
Michael McCandless commented on LUCENE-2960:
--------------------------------------------
{quote}
bq. Oh yeah. But then we'd clone the full IWC on every set... this seems like
overkill in the name of "purity".
So what? What exactly is overkill? Few wasted bytes and CPU ns for an object
that's created a couple of times during application lifetime?
There are also builders, which are very similar to what Steven is proposing.
{quote}
I don't like that this'd be an O(N*M) cost API when you use it. Sure,
N and M are tiny, and you use this API very rarely, but I still don't
like it ;)
In addition, because this is all in the name of "purity" which as far
as I can see has no real value besides "purity". It's... incestuous.
And, I'm a pragmatist, I guess.
{quote}
An annotation processor that looks for @Live annotations on setters, then
generates source for a LiveIWC class, an instance of which would be returned by
IW.getConfig(), would solve the duplication/separation problem. No extension
required: LiveIWC could forward all getters and the live setters to a cloned
IWC.
{quote}
I think this is overkill? (Ie to have @Live compile to LiveIWC vs
InitIWC). Though, @Live would be nice for jdocs?
bq. You win the fact that this is such an expert thing, and it should not
confuse 99% of users who won't need to change these settings in a live way.
Right -- simple things should be simple and complex things should be
possible.
The current patch achieves this -- the 99% of "simple" users that just
want to config IW and create it find all of the config in one place.
The 1% complex cases (need to change live settings) are able to do so,
but must read the jdocs for each setter to verify it's supported. The
API should be designed around the simple users not the complex ones,
as the current patch does.
So... I think the current patch is ready to commit (except, I'll
remove the </html> tag for infoStream & defaultInfoStream).
> Allow (or bring back) the ability to setRAMBufferSizeMB on an open IndexWriter
> ------------------------------------------------------------------------------
>
> Key: LUCENE-2960
> URL: https://issues.apache.org/jira/browse/LUCENE-2960
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Shay Banon
> Priority: Blocker
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2960.patch
>
>
> In 3.1 the ability to setRAMBufferSizeMB is deprecated, and removed in trunk.
> It would be great to be able to control that on a live IndexWriter. Other
> possible two methods that would be great to bring back are
> setTermIndexInterval and setReaderTermsIndexDivisor. Most of the other
> setters can actually be set on the MergePolicy itself, so no need for setters
> for those (I think).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
