lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@anyware-tech.com>
Subject Re: [jira] Commented: (LUCENE-648) Allow changing of ZIP compression level for compressed fields
Date Sat, 12 Aug 2006 14:27:25 GMT
Le Vendredi 11 Août 2006 16:00, robert engels a écrit :
> 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.

I agree with you.
The API should be kept compatible between versions, but what about breaking 
the compatibility in trunk? Is this will ba a problem is the function 
Fieldable.isCompressed() is removed ?

Nicolas

> 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: java-dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message