[ 
https://issues.apache.org/jira/browse/LUCENE-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15559753#comment-15559753
 ] 

Adrien Grand commented on LUCENE-7283:
--------------------------------------

On the other hand, doc values have been there for 4 years now. Like Solr, 
Elasticsearch has some history with FieldCache which makes the removal take 
time. But it is on the way out: the upcoming release based on Lucene 6 will 
only allow it on text fields, and as an opt-in (disabled by default) and all 
other fields (numerics, keywords, etc.) will enforce usage of doc values for 
sorting or faceting. And I truly hope that we can entirely get rid of it when 
we upgrade to Lucene 7. Now that we have had doc values for 4 years, I think 
it's really time to get rid of FieldCache. Apps that truly need it for a bit 
longer for backward compatibility guarantees can still fork the code like Mike 
suggested.

> Move SlowCompositeReaderWrapper and uninverting package to solr sources
> -----------------------------------------------------------------------
>
>                 Key: LUCENE-7283
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7283
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 6.1, master (7.0)
>
>         Attachments: LUCENE-7283.patch
>
>
> Spinoff from LUCENE-6766, where we fixed index-time sorting to have first 
> class support in Lucene's ore, and no longer use 
> {{SlowCompositeReaderWrapper}}.
> This is a dangerous, long living class, that tries to pretend a set of N 
> segments is actually just a single segment.  It's a leaky abstraction, has 
> poor performance, and puts undue pressure on the APIs of new Lucene features 
> to try to keep up this illusion.
> With LUCENE-6766, finally all usage of this class (except for 
> {{UninvertedReader}} tests, which should maybe also move out?) has been 
> removed from Lucene, so I think we should move it to Solr.  This may also 
> lead to a solution for LUCENE-7086 since e.g. the class could tap into solr's 
> schema to "know" how to handle points fields properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Reply via email to