+1, if we can find some clean way of doing it that doesn't rely on file length on read (ie, to seek backwards to the header).
Mike McCandless http://blog.mikemccandless.com On Tue, Jun 26, 2012 at 11:32 AM, Robert Muir <[email protected]> wrote: > Just looking at the previous thread, I wonder if we should consider > removing AppendingCodec and just removing this seek stuff. > > Currently this is essentially metadata stuff in terms dict/index (e.g. > terms dict field summary section and offsets for each field in terms > index: > https://builds.apache.org/job/Lucene-trunk/javadoc/core/org/apache/lucene/codecs/lucene40/Lucene40PostingsFormat.html) > > I know the typical argument for keeping this stuff is that we would > need to rely upon additional file operations (e.g. length), and we > want to limit that, but this isn't the only possible solution, e.g. we > could write a read-once file with this metadata thats just slurped in. > > And really relying upon seek at write could be viewed as just as bad > as relying upon length, obviously we know some filesystems dont > support it. > > > -- > lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
