[ https://issues.apache.org/jira/browse/LUCENE-6319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490665#comment-14490665 ]
Elliott Bradshaw edited comment on LUCENE-6319 at 4/11/15 1:03 AM: ------------------------------------------------------------------- Ryan, no worries. I figured that this might not be the top of the priority list. Here's my shot at a patch. I added two new classes, AbstractOneMerge and DelegatingOneMerge. I didn't want to overclutter OneMerge with a ton of getters and setters, so I moved most of that logic to AbstractOneMerge. DelegatingOneMerge could extend AbstractOneMerge instead of OneMerge, but that would require clients to change their references from OneMerge to AbstractOneMerge. I figured this was a decent compromise, but any other opinions would be appreciated. SortingOneMerge has been modified to extend DelegatingOneMerge. Almost all of the changes are internal and have been applied to IndexWriter, etc. The only public API changes are the moving of OneMerge.segments, rateLimiter and totalMaxDoc behind public getter methods. was (Author: ebradshaw): Here's a shot at a patch. I added two new classes, AbstractOneMerge and DelegatingOneMerge. I didn't want to overclutter OneMerge with a ton of getters and setters, so I moved most of that logic to AbstractOneMerge. DelegatingOneMerge could extend AbstractOneMerge instead of OneMerge, but that would require clients to change their references from OneMerge to AbstractOneMerge. I figured this was a decent compromise, but any other opinions would be appreciated. SortingOneMerge has been modified to extend DelegatingOneMerge. Almost all of the changes are internal and have been applied to IndexWriter, etc. The only public API changes are the moving of OneMerge.segments, rateLimiter and totalMaxDoc behind public getter methods. > Delegating OneMerge > ------------------- > > Key: LUCENE-6319 > URL: https://issues.apache.org/jira/browse/LUCENE-6319 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index > Reporter: Elliott Bradshaw > Attachments: SOLR-6319.patch > > > 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! -- 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