[
https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294632#comment-13294632
]
Michael McCandless commented on LUCENE-4132:
--------------------------------------------
Please don't rush this Shai.
I still don't like the added complexity of the current patch. I do
think compile-time checking of live configuration would be neat/nice to
have (for expert users) but not at the cost of the added complexity
(abstract classes, generics) of the current patch.
This is too much for what should be (is, today) a simple configuration
class. I'd rather keep what we have today.
Maybe we can somehow simplify the patch while enabling strong type
checking of what's live and what isn't? Or, we can enable the type
checking, but dynamically at runtime; this way at least you'd get an
exception if you tried to change something. Or, stop chainging (return
void from all setters)... then the subclassing is straightforward. Or,
we simply improve javadocs. All of these options would be an
improvement.
Or, we just keep what we have today... changing live settings is an
expert use case. We shouldn't make our code more complex for it.
You've already done the hardest part here (figuring out what is live and
what isn't)!
> 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, 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
