lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elliott Bradshaw (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LUCENE-6319) Delegating OneMerge
Date Sat, 11 Apr 2015 01:04:14 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message