If you make the compression external this is already done. In order
to do what the poster requires, you still need to read and update
fields without reading the entire document. You just do this at a
binary field level, and do all of he compression/decompression
externally.
I think putting the compression into Lucene needlessly complicates
matters. All that is required is in place field updating, and binary
field support.
On Aug 11, 2006, at 6:07 AM, Michael McCandless wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
