incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Barton (JIRA)" <>
Subject [jira] [Commented] (BLUR-341) Fix term enumeration
Date Sat, 09 Aug 2014 20:34:11 GMT


Garrett Barton commented on BLUR-341:

So I settled on
public abstract String readTerm(BytesRef ref)

I implemented it for all the types currently, not entirely sure if the spatial ones make sense
yet.  I have been struggling with making numerics sensible though.  
Lucene does a ton of terms per number as you know and I personally think that its less useful
to return all the internal terms vs the real ones.  My approach was to discard anything that
had a shift associated with it, and that is indeed giving me the right originating numbers
back. (IndexManager does a null check on the readTerms call, I return null if the term wasn't
an original one)  The problem is I'm worried about time to return, for 3 doubles I have over
75k terms in the index to run through.   I might be spinning a really long time to pull back
a decent number of terms with a real sized index.

Also the blur shell seems to hang with term queries, not sure why.  Client works fine so thinking
that will be another bug to fix the shell.


> Fix term enumeration
> --------------------
>                 Key: BLUR-341
>                 URL:
>             Project: Apache Blur
>          Issue Type: Bug
>          Components: Blur
>    Affects Versions: 0.2.2
>            Reporter: Aaron McCurry
>             Fix For: 0.2.4
> When using the terms call in blur the raw terms are returned this works for string and
text types.  However the numeric types, gis etc, do not return human readable values.
> This would be highly useful for typeahead lookups on numeric types.

This message was sent by Atlassian JIRA

View raw message