Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <1276046119.1249344314808.JavaMail.jira@brutus>
Date: Mon, 3 Aug 2009 17:05:14 -0700 (PDT)
From: "Mark Miller (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-1763) MergePolicy should require an
 IndexWriter upon construction
In-Reply-To: <953278362.1248681620951.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738692#action_12738692 ] 

Mark Miller commented on LUCENE-1763:
-------------------------------------

bq. I think subclassing LMP is also extremely advanced, ie, it's OK to make an exception to our back-compat policy.

I don't disagree, especially since MergePolicy was already marked as experimental and subject to change - but just as a history note: its not just subclasses it breaks - I'm sure its rare, but Solr instantiates a MergePolicy with newInstance, which now fails because you have to pass an IndexWriter.

> MergePolicy should require an IndexWriter upon construction
> -----------------------------------------------------------
>
>                 Key: LUCENE-1763
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1763
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Index
>            Reporter: Shai Erera
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 2.9
>
>         Attachments: LUCENE-1763.patch
>
>
> MergePolicy does not require an IW upon construction, but requires one to be passed as method arg to various methods. This gives the impression as if a single MP instance can be shared across various IW instances, which is not true for all MPs (if at all). In addition, LogMergePolicy uses the IW instance passed to these methods incosistently, and is currently exposed to potential NPEs.
> This issue will change MP to require an IW instance, however for back-compat reasons the following changes will be made:
> # A new MP ctor w/ IW as arg will be introduced. Additionally, for back-compat a default ctor will also be declared which will assign null to the member IW.
> # Methods that require IW will be deprecated, and new ones will be declared.
> #* For back-compat, the new ones will not be made abstract, but will throw UOE, with a comment that they will become abstract in 3.0.
> # All current MP impls will move to use the member instance.
> # The code which calls MP methods will continue to use the deprecated methods, passing an IW even that it won't be necessary --> this is strictly for back-compat.
> In 3.0, we'll remove the deprecated default ctor and methods, and change the code to not call the IW method variants anymore.
> I hope that I didn't leave anything out. I'm sure I'll find out when I work on the patch :).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org