> > You can't remove it on 3x, it's used by a host of deprecated methods > that access LMP's settings through IW. >
Remove means deprecate in 3x and remove in trunk. Should have been more clear about that. For LMP is > just returns the value of getUseCompoundFile (that is, until Mike's > patch that switches off compounding for large segments). > As far as I can tell, getUseCompoundFile returns the same in trunk too. The noCFS setting is not applied there. Shai On Thu, Dec 2, 2010 at 1:14 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > On Thu, Dec 2, 2010 at 4:43 AM, Simon Willnauer > <simon.willna...@googlemail.com> wrote: > > > During the work on Column Stride Fields I was actually thinking that > > Compound vs. Non-Compound should not be a global decision since we now > > have codecs and each codec should use its own way of writing files. > > Maybe it would make things way easier if we expose CFS to codecs and > > let them decide what to do. I can imagine that I want to use CFS for > > some of the codecs like Column Stride or fields that are not used for > > searches but keep individual files per codec. Just an idea.... > > +1! > > This would be a nice simplification. > > EG, it's bizarre today that on flushing a new segment, which has > nothing to do with merging, we consult the MP to decide if we need CFS > or not. > > Also, it's awkward we have getCF and also getCFDocStore. In the > future (docvalues) we may also want to separately build CFS for those > files, or not. > > Making all these decisions private to the codec makes great sense. > It's then free to CFS however it wants to. But, the codec would need > wider context, I think the full SegmentInfos, to base its decision on. > EG, LMP now conditionally builds CFS only if the segment is > "smallish" relative to total index size. > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
