You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Shai Erera <se...@gmail.com> on 2010/12/02 10:25:01 UTC
Consolidate MP and LMP
Hi
While IndexWriter declares it accepts a general MP, it will actually fail if
the given instance is not LogMP. So I wonder if we shouldn't consolidate
both of them into one, and pull up all of LMP features to MP. I think all of
LMP's features are useful for any kind of MP, and if someone wants to ignore
them he still can.
This is not the sort of change that fits well in trunk. IMO it can fit well
in 3x too since IW didn't accept anything that is not LMP. So even if it
will appear we're breaking back-compat, we actually won't. Which is another
reason, for me, why those two should be consolidated.
What do you think?
Shai
Re: Consolidate MP and LMP
Posted by Shai Erera <se...@gmail.com>.
Opened https://issues.apache.org/jira/browse/LUCENE-2790.
Shai
On Thu, Dec 2, 2010 at 2:22 PM, Earwin Burrfoot <ea...@gmail.com> wrote:
> On Thu, Dec 2, 2010 at 15:04, Shai Erera <se...@gmail.com> wrote:
> > Earwin:
> >
> > LogMergePolicy.getUseCompoundFile() is a public and not private API on
> > trunk, not deprecated and used. Perhaps you are talking about something
> > else?
>
> I was speaking of getLogMergePolicy that you mentioned:
>
> > 1) Fix IW to not case to LMP just to ask if it should create compound
> files or not. And then we can perhaps remove getLogMergePolicy from IW on
> 3x, and also removing the source for confusion.
>
> This one cannot be removed in 3x, and can safely be dropped on trunk.
>
>
> > I'm aware of LUCENE-2773, but still, if you look at LMP's
> > getUseCompoundFile() in trunk, you'll see it does not factor in the
> > noCFSRatio setting. It always returns 'useCompoundFile'.
> getUseCompoundFile() is a setting on LMP. It shouldn't be read
> anywhere at all (except maybe some client code) (and maybe should not
> exist at all).
> The actual callback that 'should' factor in noCFSRatio is called
> useCompoundFile(SIs, SI).
> But it seems Mike's patch only affects compound files created due to
> merging, not ones created when adding docs.
> Goddamn, how ugly.
>
> I think we need at least remove useCompoundFile field from OneMerge,
> and always call useCompoundFile(SIs, SI) to decide whether to pack new
> segment, regardless of how it was produced, whether by addIndexes,
> merging, writing docs, or anything else.
>
>
> --
> Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
> Phone: +7 (495) 683-567-4
> ICQ: 104465785
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Consolidate MP and LMP
Posted by Earwin Burrfoot <ea...@gmail.com>.
On Thu, Dec 2, 2010 at 15:04, Shai Erera <se...@gmail.com> wrote:
> Earwin:
>
> LogMergePolicy.getUseCompoundFile() is a public and not private API on
> trunk, not deprecated and used. Perhaps you are talking about something
> else?
I was speaking of getLogMergePolicy that you mentioned:
> 1) Fix IW to not case to LMP just to ask if it should create compound files or not. And then we can perhaps remove getLogMergePolicy from IW on 3x, and also removing the source for confusion.
This one cannot be removed in 3x, and can safely be dropped on trunk.
> I'm aware of LUCENE-2773, but still, if you look at LMP's
> getUseCompoundFile() in trunk, you'll see it does not factor in the
> noCFSRatio setting. It always returns 'useCompoundFile'.
getUseCompoundFile() is a setting on LMP. It shouldn't be read
anywhere at all (except maybe some client code) (and maybe should not
exist at all).
The actual callback that 'should' factor in noCFSRatio is called
useCompoundFile(SIs, SI).
But it seems Mike's patch only affects compound files created due to
merging, not ones created when adding docs.
Goddamn, how ugly.
I think we need at least remove useCompoundFile field from OneMerge,
and always call useCompoundFile(SIs, SI) to decide whether to pack new
segment, regardless of how it was produced, whether by addIndexes,
merging, writing docs, or anything else.
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Phone: +7 (495) 683-567-4
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidate MP and LMP
Posted by Shai Erera <se...@gmail.com>.
Earwin:
LogMergePolicy.getUseCompoundFile() is a public and not private API on
trunk, not deprecated and used. Perhaps you are talking about something
else?
I'm aware of LUCENE-2773, but still, if you look at LMP's
getUseCompoundFile() in trunk, you'll see it does not factor in the
noCFSRatio setting. It always returns 'useCompoundFile'.
Shai
On Thu, Dec 2, 2010 at 1:28 PM, Simon Willnauer <
simon.willnauer@googlemail.com> wrote:
> On Thu, Dec 2, 2010 at 12:14 PM, Michael McCandless
> <lu...@mikemccandless.com> wrote:
> > On Thu, Dec 2, 2010 at 4:43 AM, Simon Willnauer
> > <si...@googlemail.com> wrote:
> >
> >> During the work on Column Stride Fields I was actually thinking that
> >> Compound vs. Non-Compound should not be a global decision since we now
> >> have codecs and each codec should use its own way of writing files.
> >> Maybe it would make things way easier if we expose CFS to codecs and
> >> let them decide what to do. I can imagine that I want to use CFS for
> >> some of the codecs like Column Stride or fields that are not used for
> >> searches but keep individual files per codec. Just an idea....
> >
> > +1!
> >
> > This would be a nice simplification.
>
> I created an issue for this: LUCENE-2789
>
>
> simon
> >
> > EG, it's bizarre today that on flushing a new segment, which has
> > nothing to do with merging, we consult the MP to decide if we need CFS
> > or not.
> >
> > Also, it's awkward we have getCF and also getCFDocStore. In the
> > future (docvalues) we may also want to separately build CFS for those
> > files, or not.
> >
> > Making all these decisions private to the codec makes great sense.
> > It's then free to CFS however it wants to. But, the codec would need
> > wider context, I think the full SegmentInfos, to base its decision on.
> > EG, LMP now conditionally builds CFS only if the segment is
> > "smallish" relative to total index size.
> >
> > Mike
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Consolidate MP and LMP
Posted by Simon Willnauer <si...@googlemail.com>.
On Thu, Dec 2, 2010 at 12:14 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> On Thu, Dec 2, 2010 at 4:43 AM, Simon Willnauer
> <si...@googlemail.com> wrote:
>
>> During the work on Column Stride Fields I was actually thinking that
>> Compound vs. Non-Compound should not be a global decision since we now
>> have codecs and each codec should use its own way of writing files.
>> Maybe it would make things way easier if we expose CFS to codecs and
>> let them decide what to do. I can imagine that I want to use CFS for
>> some of the codecs like Column Stride or fields that are not used for
>> searches but keep individual files per codec. Just an idea....
>
> +1!
>
> This would be a nice simplification.
I created an issue for this: LUCENE-2789
simon
>
> EG, it's bizarre today that on flushing a new segment, which has
> nothing to do with merging, we consult the MP to decide if we need CFS
> or not.
>
> Also, it's awkward we have getCF and also getCFDocStore. In the
> future (docvalues) we may also want to separately build CFS for those
> files, or not.
>
> Making all these decisions private to the codec makes great sense.
> It's then free to CFS however it wants to. But, the codec would need
> wider context, I think the full SegmentInfos, to base its decision on.
> EG, LMP now conditionally builds CFS only if the segment is
> "smallish" relative to total index size.
>
> Mike
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidate MP and LMP
Posted by Earwin Burrfoot <ea...@gmail.com>.
On Thu, Dec 2, 2010 at 14:19, Shai Erera <se...@gmail.com> wrote:
>> You can't remove it on 3x, it's used by a host of deprecated methods
>> that access LMP's settings through IW.
>
> Remove means deprecate in 3x and remove in trunk. Should have been more
> clear about that.
We can drop it from trunk right away. It is private and no longer
used. I said - I just missed it when dropping deprecations.
>> For LMP is
>> just returns the value of getUseCompoundFile (that is, until Mike's
>> patch that switches off compounding for large segments).
>
> As far as I can tell, getUseCompoundFile returns the same in trunk too. The
> noCFS setting is not applied there.
https://issues.apache.org/jira/browse/LUCENE-2773
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Phone: +7 (495) 683-567-4
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidate MP and LMP
Posted by Shai Erera <se...@gmail.com>.
>
> You can't remove it on 3x, it's used by a host of deprecated methods
> that access LMP's settings through IW.
>
Remove means deprecate in 3x and remove in trunk. Should have been more
clear about that.
For LMP is
> just returns the value of getUseCompoundFile (that is, until Mike's
> patch that switches off compounding for large segments).
>
As far as I can tell, getUseCompoundFile returns the same in trunk too. The
noCFS setting is not applied there.
Shai
On Thu, Dec 2, 2010 at 1:14 PM, Michael McCandless <
lucene@mikemccandless.com> wrote:
> On Thu, Dec 2, 2010 at 4:43 AM, Simon Willnauer
> <si...@googlemail.com> wrote:
>
> > During the work on Column Stride Fields I was actually thinking that
> > Compound vs. Non-Compound should not be a global decision since we now
> > have codecs and each codec should use its own way of writing files.
> > Maybe it would make things way easier if we expose CFS to codecs and
> > let them decide what to do. I can imagine that I want to use CFS for
> > some of the codecs like Column Stride or fields that are not used for
> > searches but keep individual files per codec. Just an idea....
>
> +1!
>
> This would be a nice simplification.
>
> EG, it's bizarre today that on flushing a new segment, which has
> nothing to do with merging, we consult the MP to decide if we need CFS
> or not.
>
> Also, it's awkward we have getCF and also getCFDocStore. In the
> future (docvalues) we may also want to separately build CFS for those
> files, or not.
>
> Making all these decisions private to the codec makes great sense.
> It's then free to CFS however it wants to. But, the codec would need
> wider context, I think the full SegmentInfos, to base its decision on.
> EG, LMP now conditionally builds CFS only if the segment is
> "smallish" relative to total index size.
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Consolidate MP and LMP
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Thu, Dec 2, 2010 at 4:43 AM, Simon Willnauer
<si...@googlemail.com> wrote:
> During the work on Column Stride Fields I was actually thinking that
> Compound vs. Non-Compound should not be a global decision since we now
> have codecs and each codec should use its own way of writing files.
> Maybe it would make things way easier if we expose CFS to codecs and
> let them decide what to do. I can imagine that I want to use CFS for
> some of the codecs like Column Stride or fields that are not used for
> searches but keep individual files per codec. Just an idea....
+1!
This would be a nice simplification.
EG, it's bizarre today that on flushing a new segment, which has
nothing to do with merging, we consult the MP to decide if we need CFS
or not.
Also, it's awkward we have getCF and also getCFDocStore. In the
future (docvalues) we may also want to separately build CFS for those
files, or not.
Making all these decisions private to the codec makes great sense.
It's then free to CFS however it wants to. But, the codec would need
wider context, I think the full SegmentInfos, to base its decision on.
EG, LMP now conditionally builds CFS only if the segment is
"smallish" relative to total index size.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidate MP and LMP
Posted by Simon Willnauer <si...@googlemail.com>.
Shai, I always have trouble to figure our what you are talking about
in the first place since you are never introducing the abbreviations
you are using :)
->> Consolidate MP and LMP (WTF) :)
On Thu, Dec 2, 2010 at 10:33 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> Hmm... but MegePolicy is our abstract base class, and LogMergePolicy
> adds alot of concrete stuff, ie choosing merges according to "level"
> so that you get an exponential staircase of segments in your index.
ah MergePolicy :)
>
> Conceptually it seems like they are separate? Like if another merge
> policy came along that had the freedom to pick variable-mergeFactor
> segments to merge at once... shouldn't it subclass MP? Or, say we fix
> IW to allow out-of-order merges, shouldn't that also subclass MP and
> not LMP?
I agree we should stick to that but requiring LMP in IW should be
fixed really. I actually see no reason why we should rely on
LogMergePolicy in IW and it should be easy to move the required
methods up to the MergePolicy..
>
> I do agree IW requires LMP in some places, but isn't this limited to
> certain methods, eg set/getUseCompoundFile? Maybe we can move just
> these methods up?
+1
During the work on Column Stride Fields I was actually thinking that
Compound vs. Non-Compound should not be a global decision since we now
have codecs and each codec should use its own way of writing files.
Maybe it would make things way easier if we expose CFS to codecs and
let them decide what to do. I can imagine that I want to use CFS for
some of the codecs like Column Stride or fields that are not used for
searches but keep individual files per codec. Just an idea....
Simon
>
> Mike
>
> On Thu, Dec 2, 2010 at 4:25 AM, Shai Erera <se...@gmail.com> wrote:
>> Hi
>>
>> While IndexWriter declares it accepts a general MP, it will actually fail if
>> the given instance is not LogMP. So I wonder if we shouldn't consolidate
>> both of them into one, and pull up all of LMP features to MP. I think all of
>> LMP's features are useful for any kind of MP, and if someone wants to ignore
>> them he still can.
>>
>> This is not the sort of change that fits well in trunk. IMO it can fit well
>> in 3x too since IW didn't accept anything that is not LMP. So even if it
>> will appear we're breaking back-compat, we actually won't. Which is another
>> reason, for me, why those two should be consolidated.
>>
>> What do you think?
>>
>> Shai
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidate MP and LMP
Posted by Michael McCandless <lu...@mikemccandless.com>.
Hmm... but MegePolicy is our abstract base class, and LogMergePolicy
adds alot of concrete stuff, ie choosing merges according to "level"
so that you get an exponential staircase of segments in your index.
Conceptually it seems like they are separate? Like if another merge
policy came along that had the freedom to pick variable-mergeFactor
segments to merge at once... shouldn't it subclass MP? Or, say we fix
IW to allow out-of-order merges, shouldn't that also subclass MP and
not LMP?
I do agree IW requires LMP in some places, but isn't this limited to
certain methods, eg set/getUseCompoundFile? Maybe we can move just
these methods up?
Mike
On Thu, Dec 2, 2010 at 4:25 AM, Shai Erera <se...@gmail.com> wrote:
> Hi
>
> While IndexWriter declares it accepts a general MP, it will actually fail if
> the given instance is not LogMP. So I wonder if we shouldn't consolidate
> both of them into one, and pull up all of LMP features to MP. I think all of
> LMP's features are useful for any kind of MP, and if someone wants to ignore
> them he still can.
>
> This is not the sort of change that fits well in trunk. IMO it can fit well
> in 3x too since IW didn't accept anything that is not LMP. So even if it
> will appear we're breaking back-compat, we actually won't. Which is another
> reason, for me, why those two should be consolidated.
>
> What do you think?
>
> Shai
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidate MP and LMP
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Thu, Dec 2, 2010 at 6:10 AM, Earwin Burrfoot <ea...@gmail.com> wrote:
> What the hell is mergeFactor?! Right now this LMP setting serves two
> completely separate roles at once.
> 1. it governs a maximum number of segments on a "level";
> 2. it also limits a maximum number of segments that can participate in
> a single merge (thus throttling IO randomness).
I agree these are two concepts.
We could make a MP that lets you separately control max number of
segments on a level vs how many segments are merged at once.
So eg if I allow 20 segments per level but merge 10 at once, the first
merge would happen after 20 flushed segments, but would then leave 11
segments in the index.
One nice property of such a MP is it would never "inadvertently
optimize" your index, which is rather wasteful pay-it-forward approach
that our LMP does today that causes your index to sometimes be in an
"over merged" state.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidate MP and LMP
Posted by Earwin Burrfoot <ea...@gmail.com>.
> Hmm .. now that I look closely at it, MP has useCompundFile/DocStore
> methods, and LMP just adds getUseCompoundFile(). Why?
> And IndexWriter.addIndexes(IndexReader...) queries instanceof LMP, instead
> of calling mp.useCompoundFile()?
getUseCompoundFile - is a setting on LMP.
MP.useCompoundFile is an actual API callback that should decide
whether to use compounding or not on per-segment basis. For LMP is
just returns the value of getUseCompoundFile (that is, until Mike's
patch that switches off compounding for large segments).
IW.addIndexes should use mp.useCompoundFile, I totally agree.
> So perhaps we should:
>
> 1) Fix IW to not case to LMP just to ask if it should create compound files
> or not. And then we can perhaps remove getLogMergePolicy from IW on 3x, and
> also removing the source for confusion.
You can't remove it on 3x, it's used by a host of deprecated methods
that access LMP's settings through IW.
> 2) Look at LMP and decide if there are method we believe can be placed on a
> general MP, such as mergeFactor or maxMergeDocs. LogMP is special in how it
> picks segments for merge - that is, log-based (levels). But maxMergeDocs,
> maxMergeSize, mergeFactor, are unrelated to log/levels. This is the sort of
> functionality I'd expect to find on a general MP impl.
Truly "general" MP impl should have no settings. Only callbacks that
tell IW how to behave in different cases.
What the hell is mergeFactor?! Right now this LMP setting serves two
completely separate roles at once.
1. it governs a maximum number of segments on a "level";
2. it also limits a maximum number of segments that can participate in
a single merge (thus throttling IO randomness).
Now why do you want to push that wreck of a setting onto unsuspecting
emerging MergePolicies?
Same goes to maxMergeWhatever. Why do you want to limit user's options
by forcing him to support these settings?
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Phone: +7 (495) 683-567-4
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidate MP and LMP
Posted by Michael McCandless <lu...@mikemccandless.com>.
2010/12/2 Shai Erera <se...@gmail.com>:
> Hmm .. now that I look closely at it, MP has useCompundFile/DocStore
> methods, and LMP just adds getUseCompoundFile(). Why?
> And IndexWriter.addIndexes(IndexReader...) queries instanceof LMP, instead
> of calling mp.useCompoundFile()?
Hmm I don't know.
> So perhaps we should:
>
> 1) Fix IW to not case to LMP just to ask if it should create compound files
> or not. And then we can perhaps remove getLogMergePolicy from IW on 3x, and
> also removing the source for confusion.
Good.
> 2) Look at LMP and decide if there are method we believe can be placed on a
> general MP, such as mergeFactor or maxMergeDocs. LogMP is special in how it
> picks segments for merge - that is, log-based (levels). But maxMergeDocs,
> maxMergeSize, mergeFactor, are unrelated to log/levels. This is the sort of
> functionality I'd expect to find on a general MP impl.
We have to be careful.... eg a future MP could have a minMergeFactor
and maxMergeFactor (or, even, no bounds) and so having mergeFactor on
the parent isn't great.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidate MP and LMP
Posted by Simon Willnauer <si...@googlemail.com>.
On Thu, Dec 2, 2010 at 12:07 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> 2010/12/2 Shai Erera <se...@gmail.com>:
>> Simon, sorry about that: MP = MergePolicy, LMP = LogMergePolicy. WTF = ...
>> well I know what that is :-).
>
> That one means "wow that's funny" right? Heh.
hmm yeah :D I was just wondering what he was talking about - well now
with context its fine but for other not super into our abbreviations
that might be tough.
:)
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidate MP and LMP
Posted by Michael McCandless <lu...@mikemccandless.com>.
2010/12/2 Shai Erera <se...@gmail.com>:
> Simon, sorry about that: MP = MergePolicy, LMP = LogMergePolicy. WTF = ...
> well I know what that is :-).
That one means "wow that's funny" right? Heh.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidate MP and LMP
Posted by Shai Erera <se...@gmail.com>.
Simon, sorry about that: MP = MergePolicy, LMP = LogMergePolicy. WTF = ...
well I know what that is :-).
In 3x, IW.getLogMergePolicy which is called by some public (albeit
deprecated) API throws IllegalArgumentException if MP is not LMP. In trunk
this API is gone now (thanks to Earwin?), so it's less of a problem. Still,
IW queries instanceof LMP just to know whether it should create a compound
file, which is a setting unrelated to LMP. If I write my own MP, does it
mean IW will never create compound segments?
Hmm .. now that I look closely at it, MP has useCompundFile/DocStore
methods, and LMP just adds getUseCompoundFile(). Why?
And IndexWriter.addIndexes(IndexReader...) queries instanceof LMP, instead
of calling mp.useCompoundFile()?
So perhaps we should:
1) Fix IW to not case to LMP just to ask if it should create compound files
or not. And then we can perhaps remove getLogMergePolicy from IW on 3x, and
also removing the source for confusion.
2) Look at LMP and decide if there are method we believe can be placed on a
general MP, such as mergeFactor or maxMergeDocs. LogMP is special in how it
picks segments for merge - that is, log-based (levels). But maxMergeDocs,
maxMergeSize, mergeFactor, are unrelated to log/levels. This is the sort of
functionality I'd expect to find on a general MP impl.
Shai
On Thu, Dec 2, 2010 at 11:44 AM, Earwin Burrfoot <ea...@gmail.com> wrote:
> Actually, in trunk IW doesn't break on anything else.
>
> There's one private no-longer-used method I forgot to delete on my
> drop-all-deprecations spree.
> And there's a block in addIndexes, that explicitly checks instanceof,
> and only then casts to LMP.
>
> I'm against consolidating MP and LMP. MP is a damn interface!
> We should strive to make things less coupled rather than other way around.
>
> On Thu, Dec 2, 2010 at 12:25, Shai Erera <se...@gmail.com> wrote:
> > Hi
> >
> > While IndexWriter declares it accepts a general MP, it will actually fail
> if
> > the given instance is not LogMP. So I wonder if we shouldn't consolidate
> > both of them into one, and pull up all of LMP features to MP. I think all
> of
> > LMP's features are useful for any kind of MP, and if someone wants to
> ignore
> > them he still can.
> >
> > This is not the sort of change that fits well in trunk. IMO it can fit
> well
> > in 3x too since IW didn't accept anything that is not LMP. So even if it
> > will appear we're breaking back-compat, we actually won't. Which is
> another
> > reason, for me, why those two should be consolidated.
> >
> > What do you think?
> >
> > Shai
> >
>
>
>
> --
> Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
> Phone: +7 (495) 683-567-4
> ICQ: 104465785
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Consolidate MP and LMP
Posted by Earwin Burrfoot <ea...@gmail.com>.
Actually, in trunk IW doesn't break on anything else.
There's one private no-longer-used method I forgot to delete on my
drop-all-deprecations spree.
And there's a block in addIndexes, that explicitly checks instanceof,
and only then casts to LMP.
I'm against consolidating MP and LMP. MP is a damn interface!
We should strive to make things less coupled rather than other way around.
On Thu, Dec 2, 2010 at 12:25, Shai Erera <se...@gmail.com> wrote:
> Hi
>
> While IndexWriter declares it accepts a general MP, it will actually fail if
> the given instance is not LogMP. So I wonder if we shouldn't consolidate
> both of them into one, and pull up all of LMP features to MP. I think all of
> LMP's features are useful for any kind of MP, and if someone wants to ignore
> them he still can.
>
> This is not the sort of change that fits well in trunk. IMO it can fit well
> in 3x too since IW didn't accept anything that is not LMP. So even if it
> will appear we're breaking back-compat, we actually won't. Which is another
> reason, for me, why those two should be consolidated.
>
> What do you think?
>
> Shai
>
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Phone: +7 (495) 683-567-4
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org