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 Lu
Thank you Oliver for the links.
I will go through the JIRA threads to get more Info.
Best wishes
On Tue, May 24, 2016 at 2:07 PM, Oliver Kaleske wrote:
> Hi,
>
> > For example I was not able to find:
> > 1) when the method FieldType.setIndexed(true) was dropped and how to
> > change coding
>
Hmm it's curious you found determinization to be so costly since the
Levenshtein automata are already determinized.
But, yeah, converting THAT to an FST is tricky...
Mike McCandless
http://blog.mikemccandless.com
On Wed, May 25, 2016 at 2:46 PM, Luke Nezda wrote:
> Oof, sounds too tricky for
I've recently become aware that Lucene allows duplicate field names,
which essentially allows multiple values to be associated with a field.
A follow-up question is whether the order of the values is maintained...
if I store the values "A", "B", and then "C" in a given field for a
document, an
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)
Oof, sounds too tricky for me to justify pursuing right now. While
union'ing 10k Levenshtein automata was tractable, seems determinizing the
result is not (NP-hard - oops :)), let alone working out a suitably useful
conversion to an FST.
Thank you very much for input!
Kind regards,
- Luke
On Tu
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 ?
Ken,
See BooleanQuery.Builder.
p.s. nice to see you at Apache Big Data in Vancouver.
~ David
On Thu, May 19, 2016 at 4:28 PM Ken Krugler
wrote:
> Hi all,
>
> I’ve got an alternative representation in the index for numeric fields,
> and I need to construct an alternative approach for range queri