[
https://issues.apache.org/jira/browse/SOLR-18313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serhiy Bzhezytskyy updated SOLR-18313:
--------------------------------------
Issue Type: Task (was: Improvement)
> Prep for Lucene 11: switch two call sites to the newer Lucene API forms
> -----------------------------------------------------------------------
>
> Key: SOLR-18313
> URL: https://issues.apache.org/jira/browse/SOLR-18313
> Project: Solr
> Issue Type: Task
> Reporter: Serhiy Bzhezytskyy
> Priority: Major
>
> Lucene 11 removes two old API forms that Solr currently uses. Both have a
> replacement that ALREADY exists in
> the Lucene we're on today (10.4), so we can switch to the replacement now
> with no behavior change, which
> shrinks the eventual Lucene 11 upgrade.
> 1. Sorting with a "missing value" (where docs without a value in the sort
> field go). Lucene 11 removes the
> SortField.setMissingValue(...) setter; the value must be passed to the
> SortField constructor instead. This
> changes FieldType/EnumFieldType from "create the SortField, then call
> setMissingValue" to "compute the
> missing value and pass it into the constructor". Same result — missing
> values sort in the same place.
> 2. Automaton concatenation in the wildcard query parser. Lucene 11 removes
> Operations.concatenate(a, b) in
> favor of Operations.concatenate(List.of(a, b)). SolrQueryParserBase now
> calls the List form. Same behavior.
> Both replacement forms are present in Lucene 10.4 alongside the old ones, so
> there is no functional change and
> nothing to reindex. Discussed on dev@ ("[EXPERIMENT] Upgrading Solr against
> Lucene main (the future 11.0)");
> the broader Lucene 11 port and the Java-25 baseline bump are deliberately
> deferred until Lucene 11 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
