[
https://issues.apache.org/jira/browse/LUCENE-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969294#comment-13969294
]
Uwe Schindler commented on LUCENE-5596:
---------------------------------------
bq. Maybe we should support variable-length bytes in general, so that this
could also be applied to String fields? In a similar way to the fact that the
edge-ngram and the shingle filters allow to pre-index prefix and phrase
queries, I think it would also be nice to pre-index range queries.
This is a good idea. We should keep the primitive types, which support
precisionSteps on the bit level, but those types like BigDecimal or BigInteger
should maybe use precisionSteps of multiples than 8 only. In fact this would
only require to write a TokenStream that explodes every term to prefix terms,
with shift markers. By that we would not need any numeric stuff to handle those
anymore:
- PrefixTermsTokenFilter as last TokenFilter
- some generic MultiTermQuery that does a similar stuff like
NumericUtils.splitTerms(), just on the byte[] level
> Support for index/search large numeric field
> --------------------------------------------
>
> Key: LUCENE-5596
> URL: https://issues.apache.org/jira/browse/LUCENE-5596
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Kevin Wang
> Assignee: Uwe Schindler
> Attachments: LUCENE-5596.patch, LUCENE-5596.patch
>
>
> Currently if an number is larger than Long.MAX_VALUE, we can't index/search
> that in lucene as a number. For example, IPv6 address is an 128 bit number,
> so we can't index that as a numeric field and do numeric range query etc.
> It would be good to support BigInteger / BigDecimal
> I've tried use BigInteger for IPv6 in Elasticsearch and that works fine, but
> there are still lots of things to do
> https://github.com/elasticsearch/elasticsearch/pull/5758
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
