lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Ideas to refactor Filed
Date Tue, 11 Mar 2008 13:45:56 GMT


Responses below:

eks dev wrote:

> Moin Moin Michael,
> for the first issue I have crated LUCENE-1217, and for the second  
> one I have some questions.
> if we maintain length and offset internally in Field than we have  
> one, imo, theoretical "legacy performance problem" as we need to
> create new byte[length] and copy in order to preserve compatibility  
> (users expect this method to return compact array with 0 offset)
> I am talking about.
> public byte[] binaryValue();

Actually, if offset==0 and dataLength==array.length, can't we return  
the array itself?  This way legacy apps, which will pass both these  
checks, would see tiny (because of these added checks) performance  
loss?  Also, in a search setting, where doc was created from stored  
fields, I think both those checks would be true as well (unless  
FieldsReader is changed to share byte[] arrays between fields).

I think we should then deprecate binaryValue() in favor of  

> would that be acceptable, it is very small penalty and there will  
> be a way to avoid it? Anyhow, if one is using
> public void setValue(byte[] value), it is to be expected that this  
> user allready has a reference to value.  This makes this
> question rather theoretical, no?
> we could than create new methods,  getOffset() getLength()  
> getBinaryValue() that enable full spectrum and replace all uses  
> that expect 0-offset array.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message