Delegating OneMerge [LUCENE-6319]
- Dominant language
- Java
- Stars
- 3.6k
- Forks
- 1.4k
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 88
Description
In trying to integrate SortingMergePolicy into ElasticSearch, I ran into an issue where the custom merge logic was being stripped out by IndexUpgraderMergeSpecification. Related issue here:
https://github.com/elasticsearch/elasticsearch/issues/9731
In an endeavor to fix this, I attempted to create a DelegatingOneMerge that could be used to chain the different MergePolicies together. I quickly discovered this to be impossible, due to the direct member variable access of OneMerge by IndexWriter and other classes. It would be great if this variable access could be privatized and the consuming classes modified to use the appropriate getters and setters. Here's an example DelegatingOneMerge and modified OneMerge.
https://gist.github.com/ebradshaw/e0b74e9e8d4976ab9e0a
https://gist.github.com/ebradshaw/d72116a014f226076303
The downside here is that this would require an API change, as there are three public variables in OneMerge: estimatedMergeBytes, segments and totalDocCount. These would have to be moved behind public getters.
Without this change, I'm not sure how we could get the SortingMergePolicy working in ES, but if anyone has any other suggestions I'm all ears! Thanks!
---
Migrated from [LUCENE-6319](https://issues.apache.org/jira/browse/LUCENE-6319) by Elliott Bradshaw, updated May 14 2015
Attachments: [SOLR-6319.patch](https://apache.github.io/lucene-jira-archive/attachments/LUCENE-6319/SOLR-6319.patch)
Contributor guide
Research direction
Start by reviewing OneMerge and the consuming IndexWriter and IndexUpgraderMergeSpecification code, then compare the linked DelegatingOneMerge examples and SOLR-6319.patch. The change would be complete when the three public OneMerge variables are accessed through public getters and the consuming classes support delegated merge logic without breaking the API transition.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- search
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100