> But, we are trying to move FC under IR control (Martijn has a patch),
> at which point an RT IR could have its own appending impl...?

LUCENE-3360?  It's placing the field cache into IR / SR.  The RAM
reader could return it's own impl where the underlying array can be
atomically replaced (when a larger sized array is needed).  I agree
that is logical.

> But then... FC still returns fixed arrays so you can't append until we fix 
> that?

I don't think anything should depend on the size of the field cache
array.  If it does, it seems odd.  Are you preferring moving field
cache access to method calls?  What is the difference between that and
primitive array access?

For now I will create an independent field cache implementation that
is appendable.  It will only be associate-able with the DWPT / RAM
reader.  Maybe somehow it can work with LUCENE-3360 and / or the
existing static FC access system.

Still not sure how doc values fits in.

On Mon, Aug 22, 2011 at 6:48 PM, Michael McCandless
<[email protected]> wrote:
> Separate issue would make sense I think?
>
> But, we are trying to move FC under IR control (Martijn has a patch),
> at which point an RT IR could have its own appending impl...?
>
> But then... FC still returns fixed arrays so you can't append until we fix 
> that?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Mon, Aug 22, 2011 at 1:13 PM, Jason Rutherglen
> <[email protected]> wrote:
>> LUCENE-2312 needs appendable field caches.  I can include this
>> functionality into LUCENE-2312, or separate it out into a separate
>> issue / patch.
>>
>> However it would only be useful for RT / LUCENE-2312.  Also, I'm not
>> sure how this functionality relates to doc values.  If we used doc
>> values, then we would not be able to port LUCENE-2312 to Lucene 3.x.
>>
>> ---------------------------------------------------------------------
>> 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]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to