[
https://issues.apache.org/jira/browse/LUCENE-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073528#comment-13073528
]
Uwe Schindler commented on LUCENE-3354:
---------------------------------------
In general the FieldCache should come from the reader (and non-atomic readers
should throw UOE) and not from a static method of a random abstract class
somewhere in the search package. The orginal FieldCache design was broken and
there are many issues around this. This would also remove the insanity issues.
We can of course make SlowMultiReaderWrapper behave correct, but then all users
know that they do something wrong (icluding the broken Solr parts still using
TopLevel FieldCache entries).
We should start with this in 4.0! For backwards compatibility we could still
have the FieldCache class, but just delegating.
> Extend FieldCache architecture to multiple Values
> -------------------------------------------------
>
> Key: LUCENE-3354
> URL: https://issues.apache.org/jira/browse/LUCENE-3354
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Bill Bell
>
> I would consider this a bug. It appears lots of people are working around
> this limitation,
> why don't we just change the underlying data structures to natively support
> multiValued fields in the FieldCache architecture?
> Then functions() will work properly, and we can do things like easily
> geodist() on a multiValued field.
> Thoughts?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
