[
https://issues.apache.org/jira/browse/LUCENE-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969276#comment-13969276
]
Uwe Schindler edited comment on LUCENE-5596 at 4/15/14 6:56 AM:
----------------------------------------------------------------
Hi,
I agree with Robert. To mee it looks like the code duplication comes from the
original patch for ElasticSearch.
bq. Hi Robert Muir, for the NumericTokenStream, the getRawValue() and init()
both only handles long value, so I don't want to change the existing behaviour.
I'll change the field cache to bytes to see if it works.
In any case: The already existing attributes in NumericTokenStream should be
reused, they are duplicated in both classes, although the attributes are
public! The one attribute which handles the value itsself can be duplicated or
we move to BigInteger alltogether (but this has some overhead).
BigNumericUtils can be merged with NumericUtils. Please also sort the methods
next to each other, so they are grouped by purpose and then following one for
each type
FYI: There is already another issue in ES about BigDecimals and BigIntegers:
https://github.com/elasticsearch/elasticsearch/pull/5683 and
https://github.com/elasticsearch/elasticsearch/pull/5491 - It would be worth to
comine the approaches. This issue is not only about the JSON encoding, they
also talk about facetting and other stuff on these fields.
Finally, we should also add BigDecimal support. This just requires something
like double2SortableLong() for BigDecimal -> BigInteger.
was (Author: thetaphi):
Hi,
I agree with Robert. To mee it looks like the code duplication comes from the
original patch for ElasticSearch.
bq. Hi Robert Muir, for the NumericTokenStream, the getRawValue() and init()
both only handles long value, so I don't want to change the existing behaviour.
I'll change the field cache to bytes to see if it works.
In any case: The already existing attributes in NumericTokenStream should be
reused, they are duplicated in both classes, although the attributes are
public! The one attribute which handles the value itsself can be duplicated or
we move to BigInteger alltogether (but this has some overhead).
BigNumericUtils can be merged with NumericUtils. Please also sort the methods
next to each other, so they are grouped by purpose and then following one for
each type
FYI: There is already another issue in ES about BigDecimals and BigIntegers:
https://github.com/elasticsearch/elasticsearch/pull/5683 It would be worth to
comine the approaches. This issue is not only about the JSON encoding, they
also talk about facetting and other stuff on these fields.
Finally, we should also add BigDecimal support. This just requires something
like double2SortableLong() for BigDecimal -> BigInteger.
> 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]
