It seems that we don't need to provide IOContext to FieldInfos and SegmentInfo since we are reading them into memory anyway. I think you can just use a default context here without changing the constructors. Same is true for SegmentInfo
I think we should pass down "readOnce=true" for these cases? EG some
kind of caching dir (or something) would know not to bother caching
Same for del docs, terms index, doc values (well, sometimes), etc.
it seems that we should communicate the IOContext to the codec somehow. I suggest we put IOContext to SegmentWriteState and SegmentReadState that way we don't need to change the Codec interface and clutter it with internals. This would also fix mikes comment for FieldsConsumer etc.
+1 that's great.
I really don't like OneMerge I think we should add an abstract class (maybe MergeInfo) that exposes the estimatedMergeBytes, totalDocCount for now.
If we can't include OneMerge, and I agree it'd be nice not to, I think
we should try hard to pull stuff out of OneMerge that may be of
interest to a Dir impl? Maybe:
- isExternal (so Dir can know if this is addIndexes vs "normal" merging)
Regarding the IOContext class I think we should design for what we have right now and since SegementInfo is not used anywhere (as far as I can see) we should add it once we need it. OneMerge should not go in there but rather the interface / abstract class I talked about above.
I agree, let's wait until we have a need.
In fact... SegmentInfo for flush won't work: we go and open all files
for flushing, write to them, close them, and only then do we make the
So it seems like we should also have some abtracted stuff about the
to-be-flushed segment? Maybe for starters the
estimatedSegmentSizeBytes? EG, NRTCachingDir could use this to decide
whether to cache the new segment (today it fragile-ly relies on the
app to open new NRT reader frequently enough).