lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Woodward (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-8638) Remove deprecated code in master
Date Tue, 15 Jan 2019 11:00:00 GMT

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

Alan Woodward commented on LUCENE-8638:
---------------------------------------

Of the deprecations that I haven't removed from the branch yet:
 * WordDelimiterFilter, SynonymFilter, JaspellLookup and LegacyBM25Similarity are all referred
to from Solr, so we can deal with those in the related Solr issue
 * [~dweiss] was planning on dealing with the RAMDirectory deprecations, I think?
 * FuzzyQuery changed from taking a float to taking an int a long time ago, but queryparsers
still allow floats to be passed in and use the deprecated conversion methods.  This probably
needs its own issue as I think we'll need some separate deprecations in the various queryparsers
to properly remove this.
 * CharsRef has a deprecated Comparator which is still used in a couple of places.  The equivalent
BytesRef comparator was removed in LUCENE-7053, so we may be able to just get rid of this
and use CharsRef.compareTo(), but I want more eyes on it to be sure - pinging [~thetaphi‍]
and [~rcmuir ] for input on this one.
 * The Memory Codec still has a bunch of bridging code between the old random-access docvalues
implementation and the newer iterative API.  This should be simple enough to rewrite, but
I vaguely remember some discussion about removing it entirely so I want to double check we
want to keep this code before I spend any time refactoring it.
 * ClasspathResourceLoader has a deprecated constructor using the ThreadContext classloader. 
This was deprecated in LUCENE-7883 but it's still used in a couple of places, so I'd like
some input from [~thetaphi‍] as to what it should be replaced with
 * FixBrokenOffsetsFilter was added as a stopgap to help cut over token filters that potentially
produce backwards offsets.  We don't have any filters in core or analysis that require this
any more, so the question is do we leave it in to help the writers of custom token filters,
or do we remove it and tell people not to write broken code?

> Remove deprecated code in master
> --------------------------------
>
>                 Key: LUCENE-8638
>                 URL: https://issues.apache.org/jira/browse/LUCENE-8638
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Alan Woodward
>            Assignee: Alan Woodward
>            Priority: Major
>             Fix For: master (9.0)
>
>
> There are a number of deprecations in master that should be removed.  This issue is to
keep track of deprecations as a whole, some individual deprecations may require their own
issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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


Mime
View raw message