serhiy-bzhezytskyy opened a new pull request, #4644: URL: https://github.com/apache/solr/pull/4644
https://issues.apache.org/jira/browse/SOLR-12239 Enabling an index sort on an existing collection currently fails on core reload with `IndexWriter`'s `validateIndexSort` ("cannot change previous indexSort") — Lucene rejects the transition from unsorted segments to a configured sort, so today you have to delete and reindex from source. This adds a `RESORTINDEX` core-admin action that re-sorts the existing index into a target sort order and swaps it in, without reindexing. **Mechanism** (LUCENE-9484, shipped in Lucene 9.0): each existing segment reader is wrapped in a `SortingCodecReader` and merged into a fresh sort-configured `IndexWriter` via `addIndexes(CodecReader...)`; the result is swapped in with `modifyIndexProps` (the same path RestoreCore/replication use), then the writer and searcher are reopened. Note `addIndexes` does not auto-sort unsorted readers (LUCENE-8505 removed that), so the explicit `SortingCodecReader` wrap is what performs the re-sort. **Details:** - v1 (`action=RESORTINDEX&core=X&sort=...`) and v2 (`POST /api/cores/X/resort`) APIs; v1 delegates to the v2 impl. - Target sort is the `sort` param (usual Solr sort syntax), or falls back to the core's configured `SortingMergePolicy` sort if omitted. - Not supported in SolrCloud mode. - Indexes with child/nested documents are rejected (re-sorting would break the parent-child blocks). - The re-sort writer mirrors `SolrIndexConfig`'s parent-field handling so it works on child-doc-capable schemas. - Failed swap rolls back to the original index (RestoreCore's pattern). - Tests: v1 (happy path, unparseable-sort, no-sort-and-none-configured, child-doc rejection), config-sort fallback, and the v2 API directly. Ref-guide + changelog included. I see this as the migration piece that complements SOLR-13681 / #313 (making the index sort configurable) — resort an existing index, then declare the matching sort in config so new docs stay sorted. Filing as a PoC/for discussion: does this approach fit with how index sorting should evolve? Happy to adjust. I did not want to step on the config work. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
