lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] [Updated] (LUCENE-4132) IndexWriterConfig live settings
Date Wed, 13 Jun 2012 13:31:44 GMT


Shai Erera updated LUCENE-4132:

    Attachment: LUCENE-4132.patch

Patch removes ReadOnlyConfig and the tests from TestIWC that ensure that the same IWC instance
isn't shared between IWs. This is no longer needed, since now IW takes IWC and returns LiveConfig,
so it cannot be passed to another IW, simply because the compiler won't allow it.

This is a better solution IMO than maintaining an AtomicBoolean + tests that enforce that
+ RuntimeException that is known only during testing, or worse.

I don't think we should disable the Builder pattern - our tests use it, and I bet users use
it too (my code does). If it bothers anyone, he can separately change all our tests to call
the setters one per line.

The generics, as Simon said, are just a tool to save code duplication and make sure that IWC
and LC have the same getter signatures, and share the live setters.

The fact is, no user code will change by that change, and really, no Lucene developer should
be affected by it either -- this is just a configuration class, adding set/get methods to
it will be as easy as they were before. But now compile-wise, we don't let even expert users
change non-live settings.
> IndexWriterConfig live settings
> -------------------------------
>                 Key: LUCENE-4132
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Shai Erera
>            Priority: Minor
>             Fix For: 4.0, 5.0
>         Attachments: LUCENE-4132.patch, LUCENE-4132.patch
> A while ago there was a discussion about making some IW settings "live" and I remember
that RAM buffer size was one of them. Judging from IW code, I see that RAM buffer can be changed
"live" as IW never caches it.
> However, I don't remember which other settings were decided to be "live" and I don't
see any documentation in IW nor IWC for that. IW.getConfig mentions:
> {code}
> * <b>NOTE:</b> some settings may be changed on the
> * returned {@link IndexWriterConfig}, and will take
> * effect in the current IndexWriter instance.  See the
> * javadocs for the specific setters in {@link
> * IndexWriterConfig} for details.
> {code}
> But there's no text on e.g. IWC.setRAMBuffer mentioning that.
> I think that it'd be good if we make it easier for users to tell which of the settings
are "live" ones. There are few possible ways to do it:
> * Introduce a custom @live.setting tag on the relevant IWC.set methods, and add special
text for them in build.xml
> ** Or, drop the tag and just document it clearly.
> * Separate IWC to two interfaces, LiveConfig and OneTimeConfig (name proposals are welcome
!), have IWC impl both, and introduce another IW.getLiveConfig which will return that interface,
thereby clearly letting the user know which of the settings are "live".
> It'd be good if IWC itself could only expose setXYZ methods for the "live" settings though.
So perhaps, off the top of my head, we can do something like this:
> * Introduce a Config object, which is essentially what IWC is today, and pass it to IW.
> * IW will create a different object, IWC from that Config and IW.getConfig will return
> * IWC itself will only have setXYZ methods for the "live" settings.
> It adds another object, but user code doesn't change - it still creates a Config object
when initializing IW, and need to handle a different type if it ever calls IW.getConfig.
> Maybe that's not such a bad idea?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message