[
https://issues.apache.org/jira/browse/BLUR-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091896#comment-14091896
]
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.
Thoughts?
> Fix term enumeration
> --------------------
>
> Key: BLUR-341
> URL: https://issues.apache.org/jira/browse/BLUR-341
> 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
(v6.2#6252)
