lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2960) Allow (or bring back) the ability to setRAMBufferSizeMB on an open IndexWriter
Date Wed, 16 Mar 2011 16:05:29 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message