On Thu, Mar 10, 2011 at 8:23 AM, Shai Erera <ser...@gmail.com> 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 > specified up front is one thing, but if it's dynamic, we need to have code > which dynamically increases or decreases it. Increasing is not the problem, > but decreasing requires special code that flushes and discards the extra > memory. Maybe the code already exists, I haven't checked.
Actually IW handles this (RAM buffer grows or shrinks) today, or it did before the IWC change. Though I'm not sure it provoked a flush immediately (ie, it was probably on the next add/update/delete call that the flush happened); we should fix that. > I don't like setters that are all over the place either. Having said that > though, today the setters are inconsistent -- some are 'static' (meaning, > cannot change after IW created) while some are dynamic, such as the > MergePolicy settings. Because MP responds to those setters. > > One thing we can do is keep all the setters in IWC and have IW pass itself > to IWC after creation. Then, we can modify certain settings in IWC to notify > IW of these changes. But it's complicated. +1 -- I think this is the best option? Ie, we leave all setters/getters in IWC, but we make it clear (in javadocs) which settings are "live" and which must be done before init'ing the IW. If we want to be anal about it we can throw IllegalStateExc if you try to change a static setting after IW has bound to the IWC. -- Mike http://blog.mikemccandless.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
