[
https://issues.apache.org/jira/browse/LUCENE-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969339#comment-13969339
]
Uwe Schindler commented on LUCENE-5596:
---------------------------------------
bq. +1 for ByteRangeQuery, I'll work on a patch for that first
Maybe we should discuss the API first, I don't like people doing lots of code
refactoring without knowing how it should look like. I have more ideas, maybe
we should name it "BinaryField", which then would support all: indexing,
storing, docvalues. Currently binary only works for stored fields and so on. So
we should craefully think about that.
The precisionStep (in that case not with "bit" as unit, but full "bytes") would
just be an option for those binary terms. We can then add a BinaryRangeQuery,
that can optionally use a precision step.
Under the hood, we could also add precisionStep support for TermRangeQuery
(just an idea)...
> 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]
