Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-7094

spatial-extras BBoxStrategy and (confusingly!) PointVectorStrategy use legacy numeric encoding

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.0
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      We need to deprecate these since they work on the old encoding and provide points based alternatives.

      1. LUCENE_7094.patch
        65 kB
        David Smiley
      2. LUCENE_7094.patch
        57 kB
        David Smiley
      3. LUCENE_7094.patch
        48 kB
        David Smiley
      4. LUCENE-7094.patch
        50 kB
        Nicholas Knize
      5. LUCENE-7094.patch
        47 kB
        Nicholas Knize

        Issue Links

          Activity

          Hide
          nknize Nicholas Knize added a comment -
          • Cuts PointVectorStrategy and BBoxStrategy over to DoublePoint while supporting backcompat through static methods newInstance and newLegacyInstance this forces users of the API to conciously use newLegacyInstance for supporting old indexes. The public constructor can be added back in 7.0 when Legacy numerics are completely removed.
          • Simplifies tests by removing UninvertingReader and adding needsDocValues helper
          • Tests and javadocs updated
          Show
          nknize Nicholas Knize added a comment - Cuts PointVectorStrategy and BBoxStrategy over to DoublePoint while supporting backcompat through static methods newInstance and newLegacyInstance this forces users of the API to conciously use newLegacyInstance for supporting old indexes. The public constructor can be added back in 7.0 when Legacy numerics are completely removed. Simplifies tests by removing UninvertingReader and adding needsDocValues helper Tests and javadocs updated
          Hide
          dsmiley David Smiley added a comment -

          Thanks for working on this Nick! It's nice to see spatial-extras join the new PointValues world.

          I see you added the constant SpatialStrategy.SUFFIX_DV, and that it’s used by BBoxStrategy & PointVectorStrategy. (BTW statics should be ordered above non-statics) I see it’s used to put DocValue data in separate field names from the field name given to the strategy. Why this change? It would thwart someone using this code against an index created with 5.x. In case you didn’t know, the terms index, docValues, stored values, pointValues etc. are independent and so a field name might have data in all of them. There’s no need for a field name suffix to differentiate the type.

          I think BBoxStrategy.ComboField (private) shouldn’t be deprecated; it’s not quite tied to legacy numerics as the comment you added claims, although it can support it if someone provides a field type with the index enabled. It supports DV data, stored data, and terms index data, mostly all via the FieldType passed in. But I don’t think it can hold the PointValue data, so that would still be a reason to have the Field[] array have a variable size. If you don't get my drift, I'd be happy to take over and give it a shot. Maybe i'm overlooking something; maybe not.

          The SpatialStrategy.get/setFieldType option you added is only used by BBoxStrategy. That seems trappy to an unwitting user who doesn't know which does. And the "needsDocValues" field is set from this, yet only for numeric DV, not binary DV. I wonder if this field should be called needsNumericDocValues then? And why define it here instead of pertinent subclasses?

          I see some false && conditions added to RandomSpatialOpStrategyTestCase I don't think you meant to have in the patch; right?

          PortedSolr3Test.testIntersections: maybe move the enabling of docValues on PointVectorStrategy out to the parameters() static method? Or perhaps... arguably PVS should enable this by default since without it, one can't even do a circle query.

          Show
          dsmiley David Smiley added a comment - Thanks for working on this Nick! It's nice to see spatial-extras join the new PointValues world. I see you added the constant SpatialStrategy.SUFFIX_DV, and that it’s used by BBoxStrategy & PointVectorStrategy. (BTW statics should be ordered above non-statics) I see it’s used to put DocValue data in separate field names from the field name given to the strategy. Why this change? It would thwart someone using this code against an index created with 5.x. In case you didn’t know, the terms index, docValues, stored values, pointValues etc. are independent and so a field name might have data in all of them. There’s no need for a field name suffix to differentiate the type. I think BBoxStrategy.ComboField (private) shouldn’t be deprecated; it’s not quite tied to legacy numerics as the comment you added claims, although it can support it if someone provides a field type with the index enabled. It supports DV data, stored data, and terms index data, mostly all via the FieldType passed in. But I don’t think it can hold the PointValue data, so that would still be a reason to have the Field[] array have a variable size. If you don't get my drift, I'd be happy to take over and give it a shot. Maybe i'm overlooking something; maybe not. The SpatialStrategy.get/setFieldType option you added is only used by BBoxStrategy. That seems trappy to an unwitting user who doesn't know which does. And the "needsDocValues" field is set from this, yet only for numeric DV, not binary DV. I wonder if this field should be called needsNumericDocValues then? And why define it here instead of pertinent subclasses? I see some false && conditions added to RandomSpatialOpStrategyTestCase I don't think you meant to have in the patch; right? PortedSolr3Test.testIntersections: maybe move the enabling of docValues on PointVectorStrategy out to the parameters() static method? Or perhaps... arguably PVS should enable this by default since without it, one can't even do a circle query.
          Hide
          nknize Nicholas Knize added a comment -

          I see it’s used to put DocValue data in separate field names from the field name given to the strategy. Why this change?

          It's necessary to cut over from UninvertingReader - which still works on 5.x segments - to DocValues. If you just set DocValues.NUMERIC on a DoubleField the Double.longValue is what's stored as the DocValue (aka the truncated value).

          I think BBoxStrategy.ComboField (private) shouldn’t be deprecated

          It's unnecessary - especially once legacy numerics are removed in 7.0 since Point types lock down the FieldType. There is no need to Circumvent Field limitations, anyway.

          The SpatialStrategy.get/setFieldType option you added is only used by BBoxStrategy.

          I'm actually in favor of removing this altogether. I just left it for backcompat with applications that need it to circumvent field limitations. I meant to take it back out of PVS. I'll make that change.

          I see some false && conditions

          Good catch! Missed that.

          arguably PVS should enable this by default since without it, one can't even do a circle query.

          +1

          Show
          nknize Nicholas Knize added a comment - I see it’s used to put DocValue data in separate field names from the field name given to the strategy. Why this change? It's necessary to cut over from UninvertingReader - which still works on 5.x segments - to DocValues. If you just set DocValues.NUMERIC on a DoubleField the Double.longValue is what's stored as the DocValue (aka the truncated value). I think BBoxStrategy.ComboField (private) shouldn’t be deprecated It's unnecessary - especially once legacy numerics are removed in 7.0 since Point types lock down the FieldType. There is no need to Circumvent Field limitations, anyway. The SpatialStrategy.get/setFieldType option you added is only used by BBoxStrategy. I'm actually in favor of removing this altogether. I just left it for backcompat with applications that need it to circumvent field limitations. I meant to take it back out of PVS. I'll make that change. I see some false && conditions Good catch! Missed that. arguably PVS should enable this by default since without it, one can't even do a circle query. +1
          Hide
          dsmiley David Smiley added a comment -

          It's necessary to cut over from UninvertingReader - which still works on 5.x segments - to DocValues. If you just set DocValues.NUMERIC on a DoubleField the Double.longValue is what's stored as the DocValue (aka the truncated value).

          I don't understand that; you description sounds related to ComboField not to UninvertingReader, but I'm not sure. Tomorrow I'll try with a debugger to see why it doesn't work (presumably a test fails).

          Note that adding this field suffix will break back-compat with a 5.x index for someone using this strategy since their data won't be in a _dv suffixed field. If we need to keep the suffix, we should add a note to the CHANGES.txt that this is so.

          (RE ComboField) It's unnecessary - especially once legacy numerics are removed in 7.0 since Point types lock down the FieldType. There is no need to Circumvent Field limitations, anyway.

          Even without PointValues, it's definitely not strictly necessary. It was a convenient hack enabling the code to return exactly 5 field values instead of sometimes 9. Now with PointValues we might need 9. FYI note that DoubleDocValuesField doesn't allow setting the stored value, but ComboField can do stored value + DV in one shot.

          Show
          dsmiley David Smiley added a comment - It's necessary to cut over from UninvertingReader - which still works on 5.x segments - to DocValues. If you just set DocValues.NUMERIC on a DoubleField the Double.longValue is what's stored as the DocValue (aka the truncated value). I don't understand that; you description sounds related to ComboField not to UninvertingReader, but I'm not sure. Tomorrow I'll try with a debugger to see why it doesn't work (presumably a test fails). Note that adding this field suffix will break back-compat with a 5.x index for someone using this strategy since their data won't be in a _dv suffixed field. If we need to keep the suffix, we should add a note to the CHANGES.txt that this is so. (RE ComboField) It's unnecessary - especially once legacy numerics are removed in 7.0 since Point types lock down the FieldType. There is no need to Circumvent Field limitations, anyway. Even without PointValues, it's definitely not strictly necessary . It was a convenient hack enabling the code to return exactly 5 field values instead of sometimes 9. Now with PointValues we might need 9. FYI note that DoubleDocValuesField doesn't allow setting the stored value, but ComboField can do stored value + DV in one shot.
          Hide
          dsmiley David Smiley added a comment -

          BTW even if UninvertingReader doesn't work when the field names are the same, I think that's fine. Whoever may be using UninvertingReader should have enabled docValues. Perhaps it's a requirement, not just a suggestion, based on your observations; I'd like to see for myself but either way I think you should remove the addition of a field suffix to your patch. That will limit the changes in the patch a bit too.

          I slept on this a bit and I think we'll need a better way for BBoxStrategy users to articulate what index options they want; it's now insufficient / ambiguous to provide a FieldType:

          • terms index (legacy)
          • pointValues index?
          • docValues?
          • stored?
          • type: double or float? (needed for pointValues & docValues)

          By default we can have pointValues, docValues, type double, not stored. Perhaps a little inner builderclass would work well. For legacy purposes, we could support the fieldType but it's either-or with the builder. It may take a bit of time to make double vs float configurable so that could be a follow-on issue. As it was, it was a TODO.

          Show
          dsmiley David Smiley added a comment - BTW even if UninvertingReader doesn't work when the field names are the same, I think that's fine. Whoever may be using UninvertingReader should have enabled docValues. Perhaps it's a requirement, not just a suggestion, based on your observations; I'd like to see for myself but either way I think you should remove the addition of a field suffix to your patch. That will limit the changes in the patch a bit too. I slept on this a bit and I think we'll need a better way for BBoxStrategy users to articulate what index options they want; it's now insufficient / ambiguous to provide a FieldType: terms index (legacy) pointValues index? docValues? stored? type: double or float? (needed for pointValues & docValues) By default we can have pointValues, docValues, type double, not stored. Perhaps a little inner builderclass would work well. For legacy purposes, we could support the fieldType but it's either-or with the builder. It may take a bit of time to make double vs float configurable so that could be a follow-on issue. As it was, it was a TODO.
          Hide
          nknize Nicholas Knize added a comment -

          Updated patch includes the following:

          • Per request, ComboField deprecation has been removed. I'm still not convinced we need to keep this around but if its a blocker for the Point cut over I'm fine leaving it alone.
          • Moved get/setFieldType back to BBoxStrategy only
          • PointVectorStrategy requires docvalues without leniency
          • BBoxStrategy and PointVectorStrategy still index docvalues in a separate field. This is needed because docvalues on a DoubleField stores a long cast from the double value, resulting in truncation of the original double. This is a bug that was not caught before because the test used whole values instead of decimal values. DistanceStrategyTest.testRecipScore was updated to test on decimal values.
          Show
          nknize Nicholas Knize added a comment - Updated patch includes the following: Per request, ComboField deprecation has been removed. I'm still not convinced we need to keep this around but if its a blocker for the Point cut over I'm fine leaving it alone. Moved get/setFieldType back to BBoxStrategy only PointVectorStrategy requires docvalues without leniency BBoxStrategy and PointVectorStrategy still index docvalues in a separate field. This is needed because docvalues on a DoubleField stores a long cast from the double value, resulting in truncation of the original double. This is a bug that was not caught before because the test used whole values instead of decimal values. DistanceStrategyTest.testRecipScore was updated to test on decimal values.
          Hide
          mikemccand Michael McCandless added a comment -

          Thank you Nicholas Knize for tackling this!

          It's important to do since 1) it can uncover tricky bugs in dimensional points (LUCENE-7133) and 2) we get better numerics performance.

          Show
          mikemccand Michael McCandless added a comment - Thank you Nicholas Knize for tackling this! It's important to do since 1) it can uncover tricky bugs in dimensional points ( LUCENE-7133 ) and 2) we get better numerics performance.
          Hide
          nknize Nicholas Knize added a comment -

          Thanks Michael McCandless I think the patch is about ready (pending another review) at which point all LegacyNumerics should be deprecated in spatial-extras. I think that should leave just LUCENE-7095 and LUCENE-7096?

          Show
          nknize Nicholas Knize added a comment - Thanks Michael McCandless I think the patch is about ready (pending another review) at which point all LegacyNumerics should be deprecated in spatial-extras . I think that should leave just LUCENE-7095 and LUCENE-7096 ?
          Hide
          dsmiley David Smiley added a comment -

          I'm working on improving it... I'll have a patch for you to see tonight.

          Show
          dsmiley David Smiley added a comment - I'm working on improving it... I'll have a patch for you to see tonight.
          Hide
          dsmiley David Smiley added a comment -

          I uploaded another patch. I mostly just focused on PointVectorStrategy because it's simpler than BBoxStrategy. I touched SpatialTestCase (mostly restoring it) too. I removed the docValue field suffix, and I'm unable to reproduce the issue with UninvertingReader you spoke of. Might you see if it's really gone and if it isn't upload a patch that fails a test?

          The main thing I did with PointVectorStrategy was to show how the various stored, docValues, pointValues, and legacyNumeric options can be configured by passing in a FieldType. I want to get your opinion on this approach. From an API standpoint, it's basically the same approach that BBoxStrategy takes, although I obviously did it without using the ComboField thing which maybe is too hacky and not worth it.

          Let me know if you'd like to use Reviewboard; I'd like to so that we can better see what changes we're making... but I understand if you don't want to.

          Show
          dsmiley David Smiley added a comment - I uploaded another patch. I mostly just focused on PointVectorStrategy because it's simpler than BBoxStrategy. I touched SpatialTestCase (mostly restoring it) too. I removed the docValue field suffix, and I'm unable to reproduce the issue with UninvertingReader you spoke of. Might you see if it's really gone and if it isn't upload a patch that fails a test? The main thing I did with PointVectorStrategy was to show how the various stored, docValues, pointValues, and legacyNumeric options can be configured by passing in a FieldType. I want to get your opinion on this approach. From an API standpoint, it's basically the same approach that BBoxStrategy takes, although I obviously did it without using the ComboField thing which maybe is too hacky and not worth it. Let me know if you'd like to use Reviewboard; I'd like to so that we can better see what changes we're making... but I understand if you don't want to.
          Hide
          nknize Nicholas Knize added a comment -

          I'm unable to reproduce the issue with UninvertingReader you spoke of.

          That's because you added back UninvertingReader. The intent was to completely cut the tests over to docvalues and remove test complexity with UninvertingReader. I'm fine discussing that in a separate issue and leaving in UIR for now. I don't want this further delaying the release.

          Let me know if you'd like to use Reviewboard;

          I have no problem using Reviewboard. While I think there's some more clean up to do in these Strategies I think we've achieved the main objective for this issue with re: to the 6.0 release (cut over to Point values and deprecate LegacyNumerics)?

          Do you have any issues with me committing this and performing code/test cleanup in 6.x?

          Show
          nknize Nicholas Knize added a comment - I'm unable to reproduce the issue with UninvertingReader you spoke of. That's because you added back UninvertingReader . The intent was to completely cut the tests over to docvalues and remove test complexity with UninvertingReader . I'm fine discussing that in a separate issue and leaving in UIR for now. I don't want this further delaying the release. Let me know if you'd like to use Reviewboard; I have no problem using Reviewboard. While I think there's some more clean up to do in these Strategies I think we've achieved the main objective for this issue with re: to the 6.0 release (cut over to Point values and deprecate LegacyNumerics)? Do you have any issues with me committing this and performing code/test cleanup in 6.x?
          Hide
          dsmiley David Smiley added a comment -

          That's because you added back UninvertingReader. The intent was to completely cut the tests over to docvalues and remove test complexity with UninvertingReader. I'm fine discussing that in a separate issue and leaving in UIR for now. I don't want this further delaying the release.

          For now i'd rather continue to test that UninvertingReader works; particularly since we can feel better about the upgrade path. In some separate issue we can remove it if you feel it isn't warranted (there is some complexity in testing it, sure).

          Do you have any issues with me committing this and performing code/test cleanup in 6.x?

          Sort of... I'd rather we not commit something that should be cleaned up unless it's like way too complex to do at once. That's pretty normal. I get the sense that you feel we're in a hurry, and I have time today to help. What do you think of my patch, particularly to PointVectorStrategy? I'm willing to immediately get on doing the same approach to BBoxStrategy; it won't take long. FWIW I'm on #lucene-dev IRC to expedite any communication.

          Show
          dsmiley David Smiley added a comment - That's because you added back UninvertingReader. The intent was to completely cut the tests over to docvalues and remove test complexity with UninvertingReader. I'm fine discussing that in a separate issue and leaving in UIR for now. I don't want this further delaying the release. For now i'd rather continue to test that UninvertingReader works; particularly since we can feel better about the upgrade path. In some separate issue we can remove it if you feel it isn't warranted (there is some complexity in testing it, sure). Do you have any issues with me committing this and performing code/test cleanup in 6.x? Sort of... I'd rather we not commit something that should be cleaned up unless it's like way too complex to do at once. That's pretty normal. I get the sense that you feel we're in a hurry, and I have time today to help. What do you think of my patch, particularly to PointVectorStrategy? I'm willing to immediately get on doing the same approach to BBoxStrategy; it won't take long. FWIW I'm on #lucene-dev IRC to expedite any communication.
          Hide
          dsmiley David Smiley added a comment -

          Also, one concern I have with your last patch is that it's no longer possible to disable the index for BBoxStrategy. For example, a user may just need it for sorting/relevancy and not for any filtering. Perhaps the ComboField thingy made this less obvious, but I hope you agree my change to PointVectorStrategy (which doesn't use ComboField) clarifies these options. I should have added a negative test to demonstrate this.

          Show
          dsmiley David Smiley added a comment - Also, one concern I have with your last patch is that it's no longer possible to disable the index for BBoxStrategy. For example, a user may just need it for sorting/relevancy and not for any filtering. Perhaps the ComboField thingy made this less obvious, but I hope you agree my change to PointVectorStrategy (which doesn't use ComboField) clarifies these options. I should have added a negative test to demonstrate this.
          Hide
          nknize Nicholas Knize added a comment -

          What do you think of my patch, particularly to PointVectorStrategy?

          I like this approach. Its much more clear what's going on. +1 for taking the same approach with BBoxStrategy and for tackling the UIR issue separately.

          Show
          nknize Nicholas Knize added a comment - What do you think of my patch, particularly to PointVectorStrategy? I like this approach. Its much more clear what's going on. +1 for taking the same approach with BBoxStrategy and for tackling the UIR issue separately.
          Hide
          dsmiley David Smiley added a comment -

          Both BBoxStrategy & PointVectorStrategy:

          • all state is now final; setters are removed. The constructor has everything it needs to know. The constructor is public, and represents an alternative to the static factory methods you added, for when the caller has options to customize. Perhaps instead this should be another factory method?
          • Options are set via a passed FieldType; and there’s a getter for it.
          • The code for state, construction & createFields are very consistent now. It’s a bit dejavu but it’s not clear refactoring to reduce duplication would be worthwhile.
          • no special name prefix is needed for DocValues based field. (same as it has been)
          • some javadocs updates; remove references to legacy numerics

          BBoxStrategy:

          • the internal ComboField is gone

          PointVectorStrategy:

          • consistency with BBoxStrategy now means this has some options formerly only in BBoxStrategy: can be marked stored (default false), the index (be it PointValues or legacy numeric) is optional (default true), and DocValues is optional (default true). An error is thrown if you call makeQuery and there’s no index.

          Tests:

          • Added test for being able to turn stored on/off, the index on/off on PointVectorStrategy
          • removed automatic use of UninvertedField, and the needsDocValues overrideable method. Instead I added a utility method a test can invoke to introduce UninvertedField with the specified list of fields and the UninvertedField.Type (thus enabling testing uninverting of Double PointValues)). I know we said this could be another issue but it didn't take long and it's comforting to see it works
          • TestBBoxStrategy now tests uninverting behavior and for both legacy & pointValues

          Misc:

          • No changes to SpatialStrategy
          Show
          dsmiley David Smiley added a comment - Both BBoxStrategy & PointVectorStrategy: all state is now final; setters are removed. The constructor has everything it needs to know. The constructor is public, and represents an alternative to the static factory methods you added, for when the caller has options to customize. Perhaps instead this should be another factory method? Options are set via a passed FieldType; and there’s a getter for it. The code for state, construction & createFields are very consistent now. It’s a bit dejavu but it’s not clear refactoring to reduce duplication would be worthwhile. no special name prefix is needed for DocValues based field. (same as it has been) some javadocs updates; remove references to legacy numerics BBoxStrategy: the internal ComboField is gone PointVectorStrategy: consistency with BBoxStrategy now means this has some options formerly only in BBoxStrategy: can be marked stored (default false), the index (be it PointValues or legacy numeric) is optional (default true), and DocValues is optional (default true). An error is thrown if you call makeQuery and there’s no index. Tests: Added test for being able to turn stored on/off, the index on/off on PointVectorStrategy removed automatic use of UninvertedField, and the needsDocValues overrideable method. Instead I added a utility method a test can invoke to introduce UninvertedField with the specified list of fields and the UninvertedField.Type (thus enabling testing uninverting of Double PointValues)). I know we said this could be another issue but it didn't take long and it's comforting to see it works TestBBoxStrategy now tests uninverting behavior and for both legacy & pointValues Misc: No changes to SpatialStrategy
          Hide
          rcmuir Robert Muir added a comment -

          -1 to keep hanging on to uninverting reader in this way. It already has its own tests.

          We need to be able to e.g. get rid of it at some point and you are just being difficult here.

          If someone is going to reindex, they can reindex with docvalues too.

          Show
          rcmuir Robert Muir added a comment - -1 to keep hanging on to uninverting reader in this way. It already has its own tests. We need to be able to e.g. get rid of it at some point and you are just being difficult here. If someone is going to reindex, they can reindex with docvalues too.
          Hide
          dsmiley David Smiley added a comment -

          The attached patch modifies the previous by removing use of UninvertingReader in the tests, and thus altogether from spatial-extras. In DistanceStrategyTest I commented out use of "pointvector_legacy" with a comment explaining it requires docValues that aren't present, and mentioning Solr has such tests.

          Show
          dsmiley David Smiley added a comment - The attached patch modifies the previous by removing use of UninvertingReader in the tests, and thus altogether from spatial-extras. In DistanceStrategyTest I commented out use of "pointvector_legacy" with a comment explaining it requires docValues that aren't present, and mentioning Solr has such tests.
          Hide
          nknize Nicholas Knize added a comment -

          +1

          Show
          nknize Nicholas Knize added a comment - +1
          Hide
          dsmiley David Smiley added a comment -

          Great; who shall commit? I will tonight (~4 more hours) if I don't hear otherwise. Suggested CHANGES.txt:

          • LUCENE-7094: BBoxStrategy and PointVectorStrategy now support PointValues (in addition to legacy numeric trie). Their APIs were changed a little and also made more consistent. PointValues/Trie is optional, DocValues is optional, stored value is optional. (Nick Knize, David Smiley)
          Show
          dsmiley David Smiley added a comment - Great; who shall commit? I will tonight (~4 more hours) if I don't hear otherwise. Suggested CHANGES.txt: LUCENE-7094 : BBoxStrategy and PointVectorStrategy now support PointValues (in addition to legacy numeric trie). Their APIs were changed a little and also made more consistent. PointValues/Trie is optional, DocValues is optional, stored value is optional. (Nick Knize, David Smiley)
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit e1b45568b41bf67b48baae7b8fec5793300a6814 in lucene-solr's branch refs/heads/master from nknize
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e1b4556 ]

          • LUCENE-7094: BBoxStrategy and PointVectorStrategy now support PointValues (in addition to legacy numeric trie). Their APIs were changed a little and also made more consistent. PointValues/Trie is optional, DocValues is optional, stored value is optional.
          Show
          jira-bot ASF subversion and git services added a comment - Commit e1b45568b41bf67b48baae7b8fec5793300a6814 in lucene-solr's branch refs/heads/master from nknize [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e1b4556 ] LUCENE-7094 : BBoxStrategy and PointVectorStrategy now support PointValues (in addition to legacy numeric trie). Their APIs were changed a little and also made more consistent. PointValues/Trie is optional, DocValues is optional, stored value is optional.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit f9da8164483912cad40032387783f07e8c0cfc73 in lucene-solr's branch refs/heads/branch_6_0 from nknize
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f9da816 ]

          • LUCENE-7094: BBoxStrategy and PointVectorStrategy now support PointValues (in addition to legacy numeric trie). Their APIs were changed a little and also made more consistent. PointValues/Trie is optional, DocValues is optional, stored value is optional.
          Show
          jira-bot ASF subversion and git services added a comment - Commit f9da8164483912cad40032387783f07e8c0cfc73 in lucene-solr's branch refs/heads/branch_6_0 from nknize [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f9da816 ] LUCENE-7094 : BBoxStrategy and PointVectorStrategy now support PointValues (in addition to legacy numeric trie). Their APIs were changed a little and also made more consistent. PointValues/Trie is optional, DocValues is optional, stored value is optional.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 08dae30f738b5766b29600cf58dbaa74419ea0fa in lucene-solr's branch refs/heads/branch_6x from nknize
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=08dae30 ]

          • LUCENE-7094: BBoxStrategy and PointVectorStrategy now support PointValues (in addition to legacy numeric trie). Their APIs were changed a little and also made more consistent. PointValues/Trie is optional, DocValues is optional, stored value is optional.
          Show
          jira-bot ASF subversion and git services added a comment - Commit 08dae30f738b5766b29600cf58dbaa74419ea0fa in lucene-solr's branch refs/heads/branch_6x from nknize [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=08dae30 ] LUCENE-7094 : BBoxStrategy and PointVectorStrategy now support PointValues (in addition to legacy numeric trie). Their APIs were changed a little and also made more consistent. PointValues/Trie is optional, DocValues is optional, stored value is optional.

            People

            • Assignee:
              nknize Nicholas Knize
              Reporter:
              rcmuir Robert Muir
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development