I don't understand why the compressed fields are not just handled externally in the Document class - just add uncompress/compress methods. This way all Lucene needs to understand is binary fields, and you don't have any of these problems during merging or initial indexing.
The original poster of this issue (on java-user) raised another aspect of his use case: he needs to update documents that have large compressed fields.
Ideally, one could pull out a Document, change one of the other (not compressed) fields, then re-index it (and delete the original one), all without uncompresssing / recompressing the untouched compressed field. I guess this would require ability to mark a Field as compressed but also mark that it's already in compressed form (to avoid re-compressing it!).
It's of course always possible as a workaround do to all of this outside of Lucene (as this original poster has done), but, I think these use cases should be "in scope" for Lucene: if we are going to offer compressed fields we should try hard to make it efficient for basic use cases as well as for document updates?
Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
