You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shai Erera (JIRA)" <ji...@apache.org> on 2012/06/11 14:48:43 UTC
[jira] [Created] (LUCENE-4132) IndexWriterConfig live settings
Shai Erera created LUCENE-4132:
----------------------------------
Summary: 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
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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295394#comment-13295394 ]
Michael McCandless commented on LUCENE-4132:
--------------------------------------------
Hmm we are no longer cloning the IWC passed into IW? Maybe we shouldn't remove testReuse?
> IndexWriterConfig live settings
> -------------------------------
>
> Key: LUCENE-4132
> URL: https://issues.apache.org/jira/browse/LUCENE-4132
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292797#comment-13292797 ]
Robert Muir commented on LUCENE-4132:
-------------------------------------
{quote}
True, but I'm not aware of such use, and still someone can cache the IWC himself and pass it to multiple writers?
{quote}
I'm just talking about the general issue that IW.getConfig is not only used to change settings live.
Today our tests use this to peek at the settings on the IW (see my RandomIndexWriter example)...
> 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
>
>
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292794#comment-13292794 ]
Robert Muir commented on LUCENE-4132:
-------------------------------------
sorry, instead of nuking getConfig make it pkg-private. Things like RandomIndexWriter want to peek into some
un-live settings (like codec), I think we should still be able to look at these things for tests :)
> 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
>
>
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293784#comment-13293784 ]
Uwe Schindler commented on LUCENE-4132:
---------------------------------------
That's certified and suggested by the generics policeman. The generics are needed to make the builder API work correct (compare Enum<T extends Enum<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
>
>
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294867#comment-13294867 ]
Uwe Schindler commented on LUCENE-4132:
---------------------------------------
Hi Shai,
ignore all methods with isSynthetic() set (that are covariant overrides compatibility methods, access$xx() methods for access to private fields/ctors/...).
> 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, 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295634#comment-13295634 ]
Shai Erera commented on LUCENE-4132:
------------------------------------
bq. Shouldn't clone() be protected in LiveIndexWriterConfig and public only in IndexWriterConfig?
I guess you're right. In fact, I think that LiveIWC should not even be Cloneable, only IWC should? I'll take a loot later when I'm near the code.
> IndexWriterConfig live settings
> -------------------------------
>
> Key: LUCENE-4132
> URL: https://issues.apache.org/jira/browse/LUCENE-4132
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293781#comment-13293781 ]
Shai Erera commented on LUCENE-4132:
------------------------------------
I had a brief chat about IWC.usedByIW with Mike (was introduced in LUCENE-4084), and we both agree it's not needed anymore, as now with IW.getConfig() returning LiveConfig and IW taking IWC in its ctor, no one can pass the same instance returned from getConfig to a new IW, and so the relevant test can be nuked, together with that AtomicBoolean.
I'll nuke them then, and absorb ReadOnlyConfig into AbstractLiveConfig and stick with just two concrete clases: LiveConfig returned from IW.getConfig and IWC given to its ctor.
I'll post a patch probably tomorrow.
> 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
[jira] [Updated] (LUCENE-4132) IndexWriterConfig live settings
Posted by "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
[jira] [Updated] (LUCENE-4132) IndexWriterConfig live settings
Posted by "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
Thanks Uwe. The test is now fixed by saving all 'synthetic' methods and all 'setter' methods and verifying in the end that all of them were received from IWC too.
> 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, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (LUCENE-4132) IndexWriterConfig live settings
Posted by "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
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: 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293844#comment-13293844 ]
Shai Erera commented on LUCENE-4132:
------------------------------------
I love it too, and the changes would be too horrible. We use this builder pattern everywhere. Remember, the changes in this issue are to not confuse people, that's it. They don't cause users to change their code almost at all.
I don't quite understand what's the issue with the generics. If you don't look at IWC / LC code, it's not visible at all. I mean, in your application code, you won't see any generics.
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Simon Willnauer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293885#comment-13293885 ]
Simon Willnauer commented on LUCENE-4132:
-----------------------------------------
I think the generics here are not very complicated and also not really user facing. its only a tool here to make things nice for the user I think that justifies it. so I think this looks good though.
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292795#comment-13292795 ]
Shai Erera commented on LUCENE-4132:
------------------------------------
bq. I guess to be less confusing we should add getLiveConfig and just remove getConfig completely?
Yes that's the proposal - either getConfig or getLiveConfig, but return a LiveConfig object with all the getters of IWC, and only the setters that we want to support.
> 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
>
>
> 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
[jira] [Reopened] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Muir reopened LUCENE-4132:
---------------------------------
CHANGES.txt is mangled
> IndexWriterConfig live settings
> -------------------------------
>
> Key: LUCENE-4132
> URL: https://issues.apache.org/jira/browse/LUCENE-4132
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294626#comment-13294626 ]
Robert Muir commented on LUCENE-4132:
-------------------------------------
I still feel the same way as before. I'm sorry you don't agree with me, but please don't shove the change in.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294989#comment-13294989 ]
Michael McCandless commented on LUCENE-4132:
--------------------------------------------
Also can we rename it to LiveIndexWriterConfig? LiveConfig is too generic I think...
> 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, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Comment Edited] (LUCENE-4132) IndexWriterConfig live
settings
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293725#comment-13293725 ]
Shai Erera edited comment on LUCENE-4132 at 6/12/12 4:13 PM:
-------------------------------------------------------------
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.
was (Author: shaie):
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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294596#comment-13294596 ]
Shai Erera commented on LUCENE-4132:
------------------------------------
If there are no objections, I'd like to commit this by tomorrow.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292789#comment-13292789 ]
Robert Muir commented on LUCENE-4132:
-------------------------------------
Right, but i suppose changing live settings isnt necessarily the only use case for writer.getConfig() ?
Today someone can take the config off of there and set it on another writer (it will be privately cloned).
so i think if we want to do it this way, we could just keep getConfig as is, and add getLiveConfig which
actually returns the same object, just cast through that interface.
> 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
>
>
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13395846#comment-13395846 ]
Uwe Schindler commented on LUCENE-4132:
---------------------------------------
The 4.x commit also breaks the builds, looks like duplicate merges to same file.
> IndexWriterConfig live settings
> -------------------------------
>
> Key: LUCENE-4132
> URL: https://issues.apache.org/jira/browse/LUCENE-4132
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396233#comment-13396233 ]
Uwe Schindler commented on LUCENE-4132:
---------------------------------------
bq. The 4.x commit also breaks the builds, looks like duplicate merges to same file.
This was solved by cleaning workspace on Apache's Jenkins. Must have been a SVN problem.
> IndexWriterConfig live settings
> -------------------------------
>
> Key: LUCENE-4132
> URL: https://issues.apache.org/jira/browse/LUCENE-4132
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (LUCENE-4132) IndexWriterConfig live settings
Posted by "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
Good catch Mike ! It went away in the last changes. I re-added testReuse, with asserting that e.g. the MP instances returned from LiveIWC are not the same.
> IndexWriterConfig live settings
> -------------------------------
>
> Key: LUCENE-4132
> URL: https://issues.apache.org/jira/browse/LUCENE-4132
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292786#comment-13292786 ]
Robert Muir commented on LUCENE-4132:
-------------------------------------
I don't think we should add another Config object, making things complicated for such a very very expert use case.
Even ordinary users need to use IWC, and 99% of them don't care about changing things live.
I'm also nervous about documenting which things can/cannot be changed live unless there are unit tests for each one.
If we want to refactor indexwriter in some way that really cleans it up, but makes something "un-live", then I think
thats totally fair game and we should be able to do it, but the docs shouldnt be wrong.
> 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
>
>
> 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
[jira] [Comment Edited] (LUCENE-4132) IndexWriterConfig live
settings
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295634#comment-13295634 ]
Shai Erera edited comment on LUCENE-4132 at 6/17/12 6:15 PM:
-------------------------------------------------------------
bq. Shouldn't clone() be protected in LiveIndexWriterConfig and public only in IndexWriterConfig?
I guess you're right. In fact, I think that LiveIWC should not even be Cloneable, only IWC should? I'll take a look later when I'm near the code.
was (Author: shaie):
bq. Shouldn't clone() be protected in LiveIndexWriterConfig and public only in IndexWriterConfig?
I guess you're right. In fact, I think that LiveIWC should not even be Cloneable, only IWC should? I'll take a loot later when I'm near the code.
> IndexWriterConfig live settings
> -------------------------------
>
> Key: LUCENE-4132
> URL: https://issues.apache.org/jira/browse/LUCENE-4132
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Assigned] (LUCENE-4132) IndexWriterConfig live settings
Posted by "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 reassigned LUCENE-4132:
----------------------------------
Assignee: Shai Erera
> IndexWriterConfig live settings
> -------------------------------
>
> Key: LUCENE-4132
> URL: https://issues.apache.org/jira/browse/LUCENE-4132
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293788#comment-13293788 ]
Robert Muir commented on LUCENE-4132:
-------------------------------------
Its not certified by me. Its too confusing for a class everyone must use.
I dont care about the builder pattern, builder pattern simply isnt worth it for confusing generics on a config class.
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292788#comment-13292788 ]
Shai Erera commented on LUCENE-4132:
------------------------------------
{quote}
I don't think we should add another Config object, making things complicated for such a very very expert use case.
Even ordinary users need to use IWC, and 99% of them don't care about changing things live.
{quote}
I'm not proposing to complicate matters for 99.9% of the users. On the contrary -- users will still do:
{code}
IndexWriterConfig config = new IndexWriterConfig(...);
// configure it
IndexWriter writer = new IndexWriter(dir, config);
{code}
Only the expert users who will want to change some settings "live", will do:
{code}
Config conf = writer.getConfig(); // NOTE: it's a different type
conf.setSomething();
{code}
Config can be an IW internal type and most users won't even be aware of it. Today we document that the given IWC to IW ctor is cloned and it will remain as such. Only instead of being cloned to an IWC type, it will be cloned to a Config (or LiveConfig) type.
IWC documentation isn't changed, IW.getConfig changes by removing that NOTE, and if you care about "lively" configure IW, you can do so through LiveConfig. And we can test that type too !
> 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
>
>
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295220#comment-13295220 ]
Robert Muir commented on LUCENE-4132:
-------------------------------------
thanks, +1
> 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, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293792#comment-13293792 ]
Uwe Schindler commented on LUCENE-4132:
---------------------------------------
We could, I am against, I love IndexWriterConfig!
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292792#comment-13292792 ]
Robert Muir commented on LUCENE-4132:
-------------------------------------
ok actually i was partially wrong, one can no longer actually use the IWC from a writer since its marked as "owned".
But they can still grab it and look at stuff like getIndexDeletionPolicy, even though thats not live.
I guess to be less confusing we should add getLiveConfig and just remove getConfig completely?
> 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
>
>
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295598#comment-13295598 ]
Michael McCandless commented on LUCENE-4132:
--------------------------------------------
bq. I re-added testReuse, with asserting that e.g. the MP instances returned from LiveIWC are not the same.
Thanks!
Shouldn't clone() be protected in LiveIndexWriterConfig and public only in IndexWriterConfig?
Ie, users should never have any reason to clone the live config?
> IndexWriterConfig live settings
> -------------------------------
>
> Key: LUCENE-4132
> URL: https://issues.apache.org/jira/browse/LUCENE-4132
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293783#comment-13293783 ]
Robert Muir commented on LUCENE-4132:
-------------------------------------
I think the class hierarchy/generics are too tricky.
Why do we need generics?
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292793#comment-13292793 ]
Shai Erera commented on LUCENE-4132:
------------------------------------
bq. Today someone can take the config off of there and set it on another writer (it will be privately cloned)
True, but I'm not aware of such use, and still someone can cache the IWC himself and pass it to multiple writers?
If getConfig() returns an IWC which has setters(), that'll confuse the user for sure, because those settings won't take effect.
I prefer that getConfig return the new LiveConfig type, with few setters and all getters (i.e. all getXYZ from IWC), and let whoever want to pass the same IWC instance to other writers handle it himself.
Alternatively, we can add another ctor which takes a LiveConfig object, that is returned from getConfig(), but I prefer to avoid that until someone actually tells us that he shares the same IWC with other writers, and he cannot cache it himself?
> 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
>
>
> 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
[jira] [Updated] (LUCENE-4132) IndexWriterConfig live settings
Posted by "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
Patch removes Cloenable from LiveIWC. Now only IWC is Cloenable.
> IndexWriterConfig live settings
> -------------------------------
>
> Key: LUCENE-4132
> URL: https://issues.apache.org/jira/browse/LUCENE-4132
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293791#comment-13293791 ]
Michael McCandless commented on LUCENE-4132:
--------------------------------------------
If we remove IWC's chained setters (return void), can we simplify this?
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294427#comment-13294427 ]
Michael McCandless commented on LUCENE-4132:
--------------------------------------------
I dislike chaining ("return this" from setters) since it's so easily and often abused. Here's an example from Lucene's tests:
{noformat}
IndexWriter w = new MockIndexWriter(dir, newIndexWriterConfig(
TEST_VERSION_CURRENT, new MockAnalyzer(random())).setOpenMode(OpenMode.CREATE)
.setRAMBufferSizeMB(0.1).setMaxBufferedDocs(maxBufferedDocs).setIndexerThreadPool(new ThreadAffinityDocumentsWriterThreadPool(maxThreadStates))
.setReaderPooling(doReaderPooling).setMergePolicy(newLogMergePolicy()));
{noformat}
bq. I don't quite understand what's the issue with the generics. If you don't look at IWC / LC code, it's not visible at all. I mean, in your application code, you won't see any generics.
It's also important to keep our non-user-facing sources simple too, so
our source code is approachable to new users.
Having 4 classes, plus generics, for what ought to be a simple
configuration class, is too much in my opinion. I'd rather stick with
javadocs explaining what can and cannot be changed live. This (wanting
to change live seettings) is expert usage...
Hopefully, we can simplify the approach here.
> 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
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295269#comment-13295269 ]
Shai Erera commented on LUCENE-4132:
------------------------------------
Thanks Robert. I'll wait until Sunday and commit it.
> 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, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294939#comment-13294939 ]
Robert Muir commented on LUCENE-4132:
-------------------------------------
Can we override *all* methods so the javadocs aren't confusing.
I don't want the methods split in the javadocs between IWC and LiveConfig: LiveConfig is expert and should be a subset, not a portion.
> 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, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4132) IndexWriterConfig live settings
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293868#comment-13293868 ]
Shai Erera commented on LUCENE-4132:
------------------------------------
The generics is because I wanted to not duplicate code between LiveConfig and IWC, so that the live settings share the same setXYZ code. First I thought to write a separate LiveConfig class, but then the setter methods need to be duplicated. I'll take another look -- perhaps IWC.setRAMBuffer for instance can just delegate to a private LiveConfig instance.setter. That will keep the APIs without generics, with perhaps so jdoc duplication ...
I can take a stab at something like that, or if you have another proposal. I don't want to let go of the builder pattern though.
> 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
[jira] [Resolved] (LUCENE-4132) IndexWriterConfig live settings
Posted by "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 resolved LUCENE-4132.
--------------------------------
Resolution: Fixed
Lucene Fields: New,Patch Available (was: New)
Committed revision 1351225 (trunk) and revision 1351229 (4x).
Thanks all for your comments !
> IndexWriterConfig live settings
> -------------------------------
>
> Key: LUCENE-4132
> URL: https://issues.apache.org/jira/browse/LUCENE-4132
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (LUCENE-4132) IndexWriterConfig live settings
Posted by "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
bq. Can we override all methods so the javadocs aren't confusing.
Good idea! Done
bq. Also can we rename it to LiveIndexWriterConfig?
Done
> 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, LUCENE-4132.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (LUCENE-4132) IndexWriterConfig live settings
Posted by "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
Sorry if it came across like that, but I don't mean to rush or shove this issue in. I'm usually after consensus and I appreciate your feedback.
I took another look at this, and found a solution without generics. Funny thing is, that's the first solution that came to my mind, but I guess at the time it didn't picture well enough, so I discarded it :).
Now we have only LiveConfig and IndexWriterConfig, where IWC extends LC and overrides all setter methods. The "live" setters are overridden just to return IWC type, and call super.setXYZ(). So we don't have code dup, and whoever has IWC type at hand, will receive IWC back from all set() methods.
LC is public class but with package-private ctors, one that takes IWC (used by IndexWriter) and one that takes Analyzer+Version, to match IWC's. It contains all "live" members as private, and the others as protected, so that IWC can set them. Since it cannot be sub-classed outside the package, this is 'safe'.
The only thing that bothers me, and I'm not sure if it can be fixed, but this is not critical either, is TestIWC.testSettersChaining(). For some reason, even though I override the setters from LC in IWC, and set their return type to IWC, reflection still returns their return type as LiveConfig. This only affects the test, since if I do:
{code}
IndexWriterConfig conf;
conf.setMaxBufferedDocs(); // or any other set from LC
{code}
the return type is IWC.
If anyone knows how to solve it, please let me know, otherwise we'll just have to live with the modification to the test, and the chance that future "live" setters may be incorrectly overridden by IWC to not return IWC type That is not an error, just a convenience.
Besides that, and if I follow your comments and concerns properly, I think this is now ready to commit -- there's no extra complexity (generics, 3 classes etc.), and with better compile time protection against misuse.
> 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, 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