lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From eks dev <>
Subject Re: Ideas to refactor Filed
Date Tue, 11 Mar 2008 13:56:17 GMT
tip with extra checks is good, deprecate even better, I will update patch....

----- Original Message ----
From: Michael McCandless <>
Sent: Tuesday, 11 March, 2008 2:45:56 PM
Subject: Re: Ideas to refactor Filed


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:

Sent from Yahoo! Mail.
The World's Favourite Email

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

View raw message