[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860026#comment-16860026
]
Atri Sharma commented on LUCENE-8362:
-
Thanks for pushing this, Adrien!
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Fix For: master (9.0), 8.2
>
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860022#comment-16860022
]
ASF subversion and git services commented on LUCENE-8362:
-
Commit d2ff7ffafcd0ca65d93e481138785567c5861bac in lucene-solr's branch
refs/heads/branch_8x from Atri Sharma
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d2ff7ff ]
LUCENE-8362: Introduce DocValues Fields and Range Queries for native Range
Field Types
This commit introduces a new DocValues field and corresponding
range query for binary ranges. These classes are extended into
concrete implementations for each of Int, Long, Float and Double
range fields.
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859988#comment-16859988
]
Adrien Grand commented on LUCENE-8362:
--
FYI I slightly modified your patch to give range values a good cost()
implementation, and reduced the visibility from fields in the base doc-value
class and added some javadocs to make precommit pass. Working on the backport
now.
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859985#comment-16859985
]
ASF subversion and git services commented on LUCENE-8362:
-
Commit f84afab0083f61675498b685b8c26fca9a37c043 in lucene-solr's branch
refs/heads/master from Atri Sharma
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f84afab ]
LUCENE-8362: Introduce DocValues Fields and Range Queries for native Range
Field Types
This commit introduces a new DocValues field and corresponding
range query for binary ranges. These classes are extended into
concrete implementations for each of Int, Long, Float and Double
range fields.
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859884#comment-16859884
]
Atri Sharma commented on LUCENE-8362:
-
Thanks Adrien, attached is an updated patch
[^LUCENE-8362.patch]
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859854#comment-16859854
]
Adrien Grand commented on LUCENE-8362:
--
Thanks Atri, this looks good in general. I only spotted one issue in toString()
which calls StringBuilder#append on arrays directly instead of using
Arrays#toString in order to have a human-readable representation. Can you add
tests for the toString representation?
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859796#comment-16859796
]
Atri Sharma commented on LUCENE-8362:
-
Some minor test formatting cleanups
[^LUCENE-8362.patch]
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858906#comment-16858906
]
Atri Sharma commented on LUCENE-8362:
-
[~jpountz] Please let me know if the latest iteration needs any changes. Happy
to iterate!
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857406#comment-16857406
]
Atri Sharma commented on LUCENE-8362:
-
[~jpountz] Sure, does attached look fine?
[^LUCENE-8362.patch]
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857376#comment-16857376
]
Adrien Grand commented on LUCENE-8362:
--
Could we move it to the same package as BinaryRangeFieldRangeQuery then? I
prefer that we hide implementation details as much as possible, especially as
this one doesn't bring much, the query could actually work directly on top on
the BinaryDocValues?
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch,
> LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857363#comment-16857363
]
Atri Sharma commented on LUCENE-8362:
-
[~jpountz] Thanks, attached is an updated patch.
BinaryRangeDocValues needs to be public in order for BinaryRangeFieldRangeQuery
to access it, and they are not in same package.
[^LUCENE-8362.patch]
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch,
> LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857035#comment-16857035
]
Adrien Grand commented on LUCENE-8362:
--
This looks good in general, some minor comments:
- tests should use IndexSearcher#count instead of computing top docs just to
get the count?
- BinaryRangeDocValues doesn't need to be public?
- isCacheable could return {{DocValues.isCacheable(ctx, field);}} instead of
false
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856693#comment-16856693
]
Atri Sharma commented on LUCENE-8362:
-
Thanks Adrien!
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856672#comment-16856672
]
Adrien Grand commented on LUCENE-8362:
--
I'll have a look today.
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856668#comment-16856668
]
Atri Sharma commented on LUCENE-8362:
-
Does this patch look like in a commitable shape now? Anything that pokes the
eye? Happy to shape it further if required
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855680#comment-16855680
]
Atri Sharma commented on LUCENE-8362:
-
I have opened up a follow up Jira for the follow up:
https://issues.apache.org/jira/browse/LUCENE-8826
Will take it up once we finalize and merge this JIRA.
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855465#comment-16855465
]
Atri Sharma commented on LUCENE-8362:
-
[~jpountz] Thanks, attached is an updated patch.
Subclasses of BinaryRangeFieldRangeQuery do call super.rewrite. Did I miss a
point here?
[^LUCENE-8362.patch]
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855432#comment-16855432
]
Adrien Grand commented on LUCENE-8362:
--
Thanks [~atris] I like how this is structured in general.
+1 to follow up with another patch that adds other types of queries
Here is my feedback:
- let's remove the EQUALS query, I don't think there are good use-cases for it
- can you make fields protected rather than public in BinaryRangeDocValuesField
- hashCode on a byte[] is the identity hashcode, you might want to use
Arrays#hashcode instead, and likewise use Arrays#equals instead of == in the
equals implementation
- BinaryRangeFieldRangeQuery#toString seems to never be used as it is always
overridden and sub classes don't call "super.toString"? This seems to be the
case for rewrite() as well?
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855400#comment-16855400
]
Atri Sharma commented on LUCENE-8362:
-
[~jpountz] Another thought, BTW. Given how the patch is structured now, it
should be simple to add support for other types of range queries (CROSSES et
al). I have not added it in this iteration, but will post a follow up patch if
you recommend. WDYT?
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852087#comment-16852087
]
Atri Sharma commented on LUCENE-8362:
-
[~mgrigorov] No specific reason. I am accustomed to patches and have vim hacks
that allow easy generation of patches
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852082#comment-16852082
]
Atri Sharma commented on LUCENE-8362:
-
[~jpountz] Thanks for the comments. Attached is an updated patch:
[^LUCENE-8362.patch]
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16851628#comment-16851628
]
Martin Grigorov commented on LUCENE-8362:
-
[~atris] Off Topic: Why do you prefer working with patches ? It would be much
more convenient to comment on your changes in GitHub Pull Request UI.
One reason I can think of is if you don't have an account at GitHub and you
don't want to create one.
Patches are fine! But with a PR I think more people may join the review.
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850577#comment-16850577
]
Adrien Grand commented on LUCENE-8362:
--
Thanks Atri. I missed the part about "exactly match" in your previous comment.
In general exact matches on both the min and max value are not a good use-case
for range fields, you can do this more efficiently by concatenating the min and
max values and storing them in a StringField. Where range fields become more
interesting is when you want to find ranges that intersect, cross, contain or
are within the query range. I'd suggest starting with intersection now, and we
could potentially do the other ones as a follow-up? Maybe we could try to reuse
RangeFieldQuery#QueryType which already has the logic for matching ranges based
on various relations.
- BinaryRangeDocValues has an internal flag called collectionCompleted, which
seems to be used as a protection in case nextDoc/advance are called on an
exhausted iterator, but this should not be necessary: DocIdSetIterator javadocs
say that the behavior is undefined in such a case, we don't need to worry about
it.
- BinaryRangeDocValues allocates a new byte[] for every document, we should
avoid this as these methods are called in very tight loops.
- BinaryRangeDocValues#decodeRanges should take into account the BytesRef
offset.
- Can we move tests to a new class instead of adding to TestDocValuesQueries?
- Tests don't seem to test much, they keep indexing the same range over and
over, we should index a mix of ranges that match and others that don't?
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850544#comment-16850544
]
Atri Sharma commented on LUCENE-8362:
-
[^LUCENE-8362.patch]
[~jpountz] Attached is an updated patch. Let me know if it makes sense.
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849507#comment-16849507
]
Adrien Grand commented on LUCENE-8362:
--
This would be the right implementation indeed!
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849498#comment-16849498
]
Atri Sharma commented on LUCENE-8362:
-
[~jpountz] Thanks for your comments.
I wanted to check with you on the best way to define the scorer for
BinaryRangeFieldRangeQuery. Essentially, given the input BinaryRangeDocValues
field and the range defined for a BinaryRangeFieldRangeQuery, should we return
a ConstantScoreScorer which wraps an underlying TwoPhaseIterator, where the
iterator's matches() method checks if the input field's min and max arrays
exactly match the query's min and max arrays?
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849445#comment-16849445
]
Adrien Grand commented on LUCENE-8362:
--
I had a quick look. The code organization looks good in general. However
BinaryRangeFieldRangeQuery seems to always return an empty set of docs? We
should also improve tests to verify the set of matched documents? I noticed a
leftover in IntRange where the encode method becomes public even though you are
not using it?
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849340#comment-16849340
]
Atri Sharma commented on LUCENE-8362:
-
[^LUCENE-8362.patch]
Hi [~jpountz]
Thanks for your comments. Attached is an updated patch for the same. Please let
me know your thoughts.
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848917#comment-16848917
]
Adrien Grand commented on LUCENE-8362:
--
I like the approach, I'd just reduce visibility of new code such as
BinaryRangeDocValuesField or IntRange#encode* which don't need to be public.
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848898#comment-16848898
]
Atri Sharma commented on LUCENE-8362:
-
[^LUCENE-8362-approach2.patch]
Hi [~jpountz],
Thanks for your comments.
I have attached a PoC patch introducing a new range query type for
BinaryDocValuesField and extending it for IntRange. If this seems fine, I will
extend it to remaining types as well.
Let me know your thoughts.
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845816#comment-16845816
]
Adrien Grand commented on LUCENE-8362:
--
I agree this could be useful in conjunction with IndexOrDocValuesQuery. Some
thoughts:
* other classes handle points and doc values on separate classes (eg.
LongPoint/NumericDocValuesField, LatLonPoint/LatLonDocValuesField), we should
do the same for consistency?
* we should document the limitation that there can be at most one value per
document due to the use of binary doc values
* can we have factory methods for doc value queries, so that something can be
done with these docvalue fields, preferrably with "Slow" in the name of the
factory method, like NumericDocValuesField#newSlowRangeQuery
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845725#comment-16845725
]
Atri Sharma commented on LUCENE-8362:
-
Could we move ahead with this? This seems like a simple change which can allow
wider applications, such as using IndexOrDocValues for the new types.
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839614#comment-16839614
]
Atri Sharma commented on LUCENE-8362:
-
Attached is a patch for implementing this.
[^LUCENE-8362.patch]
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518254#comment-16518254
]
David Smiley commented on LUCENE-8362:
--
This would be a nice convenience. Today, two Fields are required to handle
both a Points + DocValues requirement.
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
