Thanks for your support, but I don't think setInfoStream makes any
sense either : )
Do we /change/ infoStreams for IW @runtime? Why can't we pass it as
constructor argument/IWC field?
Ok, just maybe, I can imagine a case, where a certain app runs
happily, then misbehaves, and then you, with some c
I agree. After IWC, the only setter left in IW is setInfoStream which makes
sense. But the rest ... assuming these config change don't happen very
often, recreating IW doesn't sound like a big thing to me. The alternative
of complicating IWC to support runtime changes -- we need to be absolutely
su
Is it really that hard to recreate IndexWriter if you have to change
the settings??
Yeah, yeah, you lose all your precious reused buffers, and maybe
there's a small indexing latency spike, when switching from old IW to
new one, but people aren't changing their IW configs several times a
second?
I
On Thu, Mar 10, 2011 at 7:28 AM, Robert Muir wrote:
> This should block the release: if IndexWriterConfig is a broken design
> then we need to revert this now before its released, not make users
> switch over and then undeprecate/revert in a future release.
+1
I think we have to sort this out,
On Thu, Mar 10, 2011 at 8:23 AM, Shai Erera wrote:
> IWC simplified IW creation - now there is only one ctor, where before there
> were multiple ones, and some settings could only be changed after IW was
> created.
>
> With IWC, our code is (can become) simpler -- e.g. RAM buffer size, if
> specif
IWC simplified IW creation - now there is only one ctor, where before there
were multiple ones, and some settings could only be changed after IW was
created.
With IWC, our code is (can become) simpler -- e.g. RAM buffer size, if
specified up front is one thing, but if it's dynamic, we need to have
On Thu, Mar 10, 2011 at 7:41 AM, Shay Banon wrote:
> I am not sure that IndexWriterConfig is bad. Its nice to be able to set all
> the upfront configurations in a single object and pass it to the
> IndexWriter. And, have the IndexWriter allow for specific setters allowing
> for real time changes (
I am not sure that IndexWriterConfig is bad. Its nice to be able to set all the
upfront configurations in a single object and pass it to the IndexWriter. And,
have the IndexWriter allow for specific setters allowing for real time changes
(those should not be done through the IndexWriterConfig).
Hi,
On Thursday, March 10, 2011 at 1:49 PM, Michael McCandless wrote:
> Hi Shay,
>
> It sounds like we should put this (ability to change RAM buffer on the
> fly) back.
>
> But, can you describe how/why you need this? Is it because you have
> many IWs open at once and you want to dynamically cha
On Thu, Mar 10, 2011 at 6:49 AM, Michael McCandless
wrote:
> Can you open an issue? Make sure it's marked fix 4.0/3.2! Thanks.
>
I'm not sure we should handle it this way: I really don't like
deprecation in one release and undeprecation in another.
So, I think we should open an issue for 3.1 a
Hi Shay,
It sounds like we should put this (ability to change RAM buffer on the
fly) back.
But, can you describe how/why you need this? Is it because you have
many IWs open at once and you want to dynamically change which gets to
use RAM?
Are there other settings that were moved to IWC that you
Heya,
I think the ability to change the RAMBufferSizeMB on a live IndexWriter
(without the need to close and open it) is an important one, and it seems like
tis deprecated on 3.1 and removed in trunk. Is there a chance to get it back?
-shay.banon
12 matches
Mail list logo
