[jira] [Updated] (LUCENE-4132) IndexWriterConfig live settings

["Shai Erera (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shai Erera updated LUCENE-4132:
-------------------------------

    Attachment: LUCENE-4132.patch

Phew, that was tricky, but here's the end result -- refactored IndexWriterConfig into the following class hierarchy:

- ReadOnlyConfig
 |_ AbstractLiveConfig
   |_ LiveConfig
   |_ IndexWriterConfig

* IndexWriter now takes ReadOnlyConfig, which is an abstract class with all abstract getters.

* LiveConfig is returned from IndexWriter.getConfig(), and is initialized with the ReadOnlyConfig given to IW. It overrides all getters to delegate the call to the given (cloned) config. It is public but with a package-private ctor.

* IndexWriterConfig is still the entry object for users to initialize an IndexWriter, and adds its own setters for the non-live settings.

* The AbstractLiveConfig in the middle is used for generics and keeping the builder pattern. That way, LiveConfig.set1() and IndexWriterConfig.set1() return the proper type (LiveConfig or IndexWriterConfig respectively).

I would have liked IW to keep getting IWC in its ctor, but there's one test that prevents it: TestIndexWriterConfig.testIWCInvalidReuse, which initializes an IW, call getConfig and passes it to another IW (which is invalid). I don't know why it's invalid, as IW clones the given IWC, but that is one reason why I had to factor the getters out to a shared ReadOnlyConfig.

ROC is not that bad though -- it kind of protects against IW changing the given config ...

At least, no user code should change following these changes, except from changing the variable type used to cache IW.getConfig() to LiveConfig, which is what we want.
                
> IndexWriterConfig live settings
> -------------------------------
>
>                 Key: LUCENE-4132
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4132
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Shai Erera
>            Priority: Minor
>             Fix For: 4.0, 5.0
>
>         Attachments: 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.
> * 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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