lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sheng <sheng...@gmail.com>
Subject Re: SortingMergePolicy in Lucene 6
Date Thu, 26 May 2016 00:26:51 GMT
Michael - That is a great article to read - thank you for the detailed
explanation of the situation! We are not in production yet, so I am ok to
wait a bit until 6 is in a more mature shape. For now, I am going to use a
LogMergePolicy instead. That does bring up another question. As we are
using Lucene-group, and as document suggests, index each group of documents
in a single commit, so they can be in the same segment. Does it place any
limitation on the merge policy we can use, as it is merging the segments
and might break the deal ? Thanks again!

On Wednesday, May 25, 2016, Michael McCandless <lucene@mikemccandless.com>
wrote:

> Sorry, yes, dimensional points and SlowCompositeReaderWrapper are not
> compatible.
>
> This class (SlowCompositeReaderWrapper) is a terrible class that we have
> been gradually (past 7 years) phasing out of Lucene.  It's a leaky
> abstraction (http://www.joelonsoftware.com/articles/LeakyAbstractions.html)
> that pretended your index has one segment when it doesn't, and it limited
> our freedoms when developing new features.
>
> Finally just today, for 7.0 anyways, we succeeded:
> https://issues.apache.org/jira/browse/LUCENE-7283
>
> That said, we have also fixed index time sorting to no longer use
> SlowCompositeReaderWrapper:
> https://issues.apache.org/jira/browse/LUCENE-6766
>
> Right now this is a 7.0 (master) only change but I plan to backport for
> 6.2 once we get 6.1 released.  Maybe you could test Lucene's current master
> and confirm points and index-time sorting work correctly for you?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Wed, May 25, 2016 at 1:10 PM, Sheng <shengcer@gmail.com
> <javascript:_e(%7B%7D,'cvml','shengcer@gmail.com');>> wrote:
>
>> It makes a call to SlowCompositeReaderWrapper in line 103, which checks if
>> field hasPointValues in line 68. If yes, it throws an exception "cannot
>> wrap points". Does this essentially mean SortingMergePolicy cannot be used
>> for index that has point values. If yes, what is the rationale behind it ?
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message