Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <44DC5E71.1070904@mikemccandless.com>
Date: Fri, 11 Aug 2006 06:39:45 -0400
From: Michael McCandless <lucene@mikemccandless.com>
User-Agent: Thunderbird 2.0a1 (X11/20060724)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: [jira] Commented: (LUCENE-648) Allow changing of ZIP compression
 level for compressed fields
References: <14516344.1155273495044.JavaMail.jira@brutus>
 <0E01A93E-85F8-40BC-A76F-8B92B4221258@ix.netcom.com>
In-Reply-To: <0E01A93E-85F8-40BC-A76F-8B92B4221258@ix.netcom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


> 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.

This is an excellent point.  Since these are just stored fields, why not 
have Lucene treat them as [opaque] binary fields so they are not touched 
during normal index operations.  And then only when a Document really 
needs to provide this value, it would decompress then?

Was there a counterbalance that justified having the compress logic 
inside the indexing code?

Mike

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