Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-8396

Add support for PointFields in Solr

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.5, 7.0
    • Component/s: None
    • Labels:
      None

      Description

      In LUCENE-6917, Michael McCandless mentioned that DimensionalValues are better than NumericFields in most respects. We should explore the benefits of using it in Solr and hence, if appropriate, switch over to using them.

      1. SOLR-8396.patch
        205 kB
        Tomás Fernández Löbbe
      2. SOLR-8396.patch
        191 kB
        Tomás Fernández Löbbe
      3. SOLR-8396.patch
        138 kB
        Tomás Fernández Löbbe
      4. SOLR-8396.patch
        85 kB
        Tomás Fernández Löbbe
      5. SOLR-8396.patch
        80 kB
        Tomás Fernández Löbbe
      6. SOLR-8396.patch
        81 kB
        Tomás Fernández Löbbe
      7. SOLR-8396.patch
        66 kB
        Tomás Fernández Löbbe
      8. SOLR-8396.patch
        54 kB
        Tomás Fernández Löbbe
      9. SOLR-8396.patch
        39 kB
        Tomás Fernández Löbbe
      10. SOLR-8396.patch
        36 kB
        Ishan Chattopadhyaya

        Issue Links

          Activity

          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited

          An extremely early patch, conforming to Yonik's law of patches.

          1. Adds a DimensionField field type (should be spelled more appropriately), which is currently only useful for a term query (e.g. "fieldname:100").
          2. Added a test to TestTrie (misplaced here)

          With LUCENE-6950 applied, this test works passes, so I am going to put up this "Yonik's law of patches" patch. More work on this later.

          Edit: This may be sufficient to do some very basic benchmarks against the trie integer field.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited An extremely early patch, conforming to Yonik's law of patches. Adds a DimensionField field type (should be spelled more appropriately), which is currently only useful for a term query (e.g. "fieldname:100"). Added a test to TestTrie (misplaced here) With LUCENE-6950 applied, this test works passes, so I am going to put up this "Yonik's law of patches" patch. More work on this later. Edit: This may be sufficient to do some very basic benchmarks against the trie integer field.
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Here is another iteration of the patch. Still mostly a copy of TrieFields.

          • Updated to current master.
          • I separated the tests and added some more.
          • Added initial implementation for range query.
          • Added stored field to be able to return the values (not sure yet if there is a better way for this)

          Still only for int fields

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Here is another iteration of the patch. Still mostly a copy of TrieFields. Updated to current master. I separated the tests and added some more. Added initial implementation for range query. Added stored field to be able to return the values (not sure yet if there is a better way for this) Still only for int fields
          Hide
          elyograg Shawn Heisey added a comment -

          I've been following along quietly.

          As Yonik has noted elsewhere, the change in Lucene means that the current Solr example configs have deprecated types in them. If we release 6.0.0 without some form of the patch for this issue, users who install 6.0.0 and don't change their configs will be unable to upgrade to 7.x – they'll be using Lucene classes that will no longer exist in the upgraded version.

          And now for the suggestion that might get me lynched:

          I believe that if we cannot get this patch into 6.0.0 before the release is made, we need to not release Solr 6.0.0. Instead we should wait until we can remove deprecated classes from our configs and release with 6.0.1 or 6.1.0 instead.

          Show
          elyograg Shawn Heisey added a comment - I've been following along quietly. As Yonik has noted elsewhere, the change in Lucene means that the current Solr example configs have deprecated types in them. If we release 6.0.0 without some form of the patch for this issue, users who install 6.0.0 and don't change their configs will be unable to upgrade to 7.x – they'll be using Lucene classes that will no longer exist in the upgraded version. And now for the suggestion that might get me lynched: I believe that if we cannot get this patch into 6.0.0 before the release is made, we need to not release Solr 6.0.0. Instead we should wait until we can remove deprecated classes from our configs and release with 6.0.1 or 6.1.0 instead.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          If we release 6.0.0 without some form of the patch for this issue, users who install 6.0.0 and don't change their configs will be unable to upgrade to 7.x

          For users upgrading from versions < 6.0, there will be issues regardless. I don't believe there is any code anywhere than upgrades numeric types in an index. So even if we get PointField in for 6.0, a person upgrading from 5.5 will have the old numeric stuff in their index, which would cease working if/when that old numeric stuff is removed. The simple answer is: we need to keep the old numeric stuff around longer regardless of when we have support for the newer Point stuff.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - If we release 6.0.0 without some form of the patch for this issue, users who install 6.0.0 and don't change their configs will be unable to upgrade to 7.x For users upgrading from versions < 6.0, there will be issues regardless. I don't believe there is any code anywhere than upgrades numeric types in an index. So even if we get PointField in for 6.0, a person upgrading from 5.5 will have the old numeric stuff in their index, which would cease working if/when that old numeric stuff is removed. The simple answer is: we need to keep the old numeric stuff around longer regardless of when we have support for the newer Point stuff.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          I agree that we need to retain our trie fields, which are based on old numerics, as well as introduce new point values based fields. Maybe both should be kept around for the entire 6x major version, but remove the former in 7x.

          As an aside, is there something we need to keep in mind due to LUCENE-7086 for implementing these new numeric fields?

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - I agree that we need to retain our trie fields, which are based on old numerics, as well as introduce new point values based fields. Maybe both should be kept around for the entire 6x major version, but remove the former in 7x. As an aside, is there something we need to keep in mind due to LUCENE-7086 for implementing these new numeric fields?
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          As an aside, is there something we need to keep in mind due to LUCENE-7086 for implementing these new numeric fields?

          I don't think we need merged point fields anywhere... but that issue will cause exceptions to be thrown even if we add a single unused point field to the index unfortunately. We'll still be able to work around it even if we can't get that issue fixed.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - As an aside, is there something we need to keep in mind due to LUCENE-7086 for implementing these new numeric fields? I don't think we need merged point fields anywhere... but that issue will cause exceptions to be thrown even if we add a single unused point field to the index unfortunately. We'll still be able to work around it even if we can't get that issue fixed.
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          we need to keep the old numeric stuff around longer regardless of when we have support for the newer Point stuff.

          I agree. If there is no update path we should keep the trie fields longer

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - we need to keep the old numeric stuff around longer regardless of when we have support for the newer Point stuff. I agree. If there is no update path we should keep the trie fields longer
          Hide
          elyograg Shawn Heisey added a comment -

          For users upgrading from versions < 6.0, there will be issues regardless.

          There has to be a limit to the upgrade scenarios we are willing to support.

          For users upgrading from 6.x with configs that they originally built for a previous major release, whether their index is fully upgraded or not, problems are to be expected. If we have to worry about supporting ancient configurations, forward progress becomes difficult.

          Another idea: Maybe the policy for deprecations in critical low-level components like Field classes needs to be different than the general case – kept around for two major releases rather than one. I'm not sure the Lucene guys would like that, because for that deprecation policy in Solr to be effective, it would need to extend to any Lucene components that the deprecated Solr Field classes depend on. For a development library, that's a very oppressive requirement.

          Show
          elyograg Shawn Heisey added a comment - For users upgrading from versions < 6.0, there will be issues regardless. There has to be a limit to the upgrade scenarios we are willing to support. For users upgrading from 6.x with configs that they originally built for a previous major release, whether their index is fully upgraded or not, problems are to be expected. If we have to worry about supporting ancient configurations, forward progress becomes difficult. Another idea: Maybe the policy for deprecations in critical low-level components like Field classes needs to be different than the general case – kept around for two major releases rather than one. I'm not sure the Lucene guys would like that, because for that deprecation policy in Solr to be effective, it would need to extend to any Lucene components that the deprecated Solr Field classes depend on. For a development library, that's a very oppressive requirement.
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Now that I think about it better, Legacy numeric types will have to be supported for all 6.x life, and can only be removed for 7.0, That's not ideal but also not terrible...
          If Solr doesn't get it by 6.0 then yes, I guess it'll have to support them until 8.0

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Now that I think about it better, Legacy numeric types will have to be supported for all 6.x life, and can only be removed for 7.0, That's not ideal but also not terrible... If Solr doesn't get it by 6.0 then yes, I guess it'll have to support them until 8.0
          Hide
          jkrupan Jack Krupansky added a comment -

          My apologies as I am still only very slowly coming up to speed on this "New Math For Lucene" stuff. It feels like there are three distinct issues in play:

          1. Desire to use the latest and greatest Lucene numeric field types. Granted, they are currently now called IntPoint, FloatPoint, DoublePoint, etc., but functionally they are still simply int, float, and double values - no semantic difference, just the class names and then some method name changes for indexing and query. My feeling is that we should preserve the legacy type names even if Lucene insists on calling them "points." Keep user schema files unchanged.
          2. Desire to work with existing data - and existing schema files. Mix metaphors: cans of worms and nested Russian dolls.
          3. Desire to auto-upgrade existing Solr index data to new "points" for better performance, reduced storage, reduced memory, reduced heap.

          Some points:

          1. Personally, I think it would be worth the effort to see if the Lucene guys can stick to to old names for IntField, et al even if the implementation is different under the hood.
          2. Maybe there will be a need to be able to open an existing numeric field, discover that it is legacy numeric field (trie), and then under the hood use some wrapper to maintain the new API for the old format. IOW, switch Solr to using the new API, even for legacy numeric fields.
          3. Seems like there is some need investigate the possibility or a NumericFieldUpgrader to rewrite a trie field as a point field. Seems like a necessary job for the Lucene guys for existing Lucene indexes, even if Solr wasn't in the picture.

          Show
          jkrupan Jack Krupansky added a comment - My apologies as I am still only very slowly coming up to speed on this "New Math For Lucene" stuff. It feels like there are three distinct issues in play: 1. Desire to use the latest and greatest Lucene numeric field types. Granted, they are currently now called IntPoint, FloatPoint, DoublePoint, etc., but functionally they are still simply int, float, and double values - no semantic difference, just the class names and then some method name changes for indexing and query. My feeling is that we should preserve the legacy type names even if Lucene insists on calling them "points." Keep user schema files unchanged. 2. Desire to work with existing data - and existing schema files. Mix metaphors: cans of worms and nested Russian dolls. 3. Desire to auto-upgrade existing Solr index data to new "points" for better performance, reduced storage, reduced memory, reduced heap. Some points: 1. Personally, I think it would be worth the effort to see if the Lucene guys can stick to to old names for IntField, et al even if the implementation is different under the hood. 2. Maybe there will be a need to be able to open an existing numeric field, discover that it is legacy numeric field (trie), and then under the hood use some wrapper to maintain the new API for the old format. IOW, switch Solr to using the new API, even for legacy numeric fields. 3. Seems like there is some need investigate the possibility or a NumericFieldUpgrader to rewrite a trie field as a point field. Seems like a necessary job for the Lucene guys for existing Lucene indexes, even if Solr wasn't in the picture.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment - - edited

          Personally, I think it would be worth the effort to see if the Lucene guys can stick to to old names for IntField

          From the Solr perspective, this doesn't bubble up to most users... our current numeric fields are called TrieIntField, TrieDoubleField, etc. Those names shouldn't be changing. We can pick whatever we want for the new solr FieldType names that will be visible in the schema. And then "int","long",etc will map to those new field types.

          In keeping with our naming convention of having FieldTypes end with Field, this leaves two obvious options:
          IntField, DoubleField, ... // I think I prefer this one
          IntPointField, DoublePointField,...

          Oh, and we should cut over to SortedNumericDocValues for multi-valued docvalues at the same time: SOLR-7878
          (NOTE: I'm not saying that whoever tackles these point types needs to also tackle SOLR-7878, but that multi-valued numeric docvalues should be unsupported in the new point types until we do it right to prevent more migration issues)

          Show
          yseeley@gmail.com Yonik Seeley added a comment - - edited Personally, I think it would be worth the effort to see if the Lucene guys can stick to to old names for IntField From the Solr perspective, this doesn't bubble up to most users... our current numeric fields are called TrieIntField, TrieDoubleField, etc. Those names shouldn't be changing. We can pick whatever we want for the new solr FieldType names that will be visible in the schema. And then "int","long",etc will map to those new field types. In keeping with our naming convention of having FieldTypes end with Field, this leaves two obvious options: IntField, DoubleField, ... // I think I prefer this one IntPointField, DoublePointField,... Oh, and we should cut over to SortedNumericDocValues for multi-valued docvalues at the same time: SOLR-7878 (NOTE: I'm not saying that whoever tackles these point types needs to also tackle SOLR-7878 , but that multi-valued numeric docvalues should be unsupported in the new point types until we do it right to prevent more migration issues)
          Hide
          elyograg Shawn Heisey added a comment -

          I have checked into how IntField evolved, because there are similarities there to what's being discussed here.

          In 4.0.0, IntField was still an active type, and none of the Lucene classes it used were deprecated either. IntField was not deprecated until 4.8 – but the main types in the collection1 example schema had been changed to the Trie types a LONG time before that. I looked as far back as the 3.5.0 example and it was already using Trie.

          With this new information, I think what you guys have been trying to say (and I wasn't catching) is that the Numeric types in Lucene are so fundamental that they should NOT be renamed/deprecated until at least 7.0, then they can be removed in 8.0 in accordance with normal deprecation policy.

          Show
          elyograg Shawn Heisey added a comment - I have checked into how IntField evolved, because there are similarities there to what's being discussed here. In 4.0.0, IntField was still an active type, and none of the Lucene classes it used were deprecated either. IntField was not deprecated until 4.8 – but the main types in the collection1 example schema had been changed to the Trie types a LONG time before that. I looked as far back as the 3.5.0 example and it was already using Trie. With this new information, I think what you guys have been trying to say (and I wasn't catching) is that the Numeric types in Lucene are so fundamental that they should NOT be renamed/deprecated until at least 7.0, then they can be removed in 8.0 in accordance with normal deprecation policy.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          Let's move further back compat discussions (that don't impact implementation of these new types) to the mailing lists.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - Let's move further back compat discussions (that don't impact implementation of these new types) to the mailing lists.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          I have some time to take a shot at working on this. If someone (Tomás Fernández Löbbe?) is working on this or planning to work on this, then I can step back / collaborate.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - I have some time to take a shot at working on this. If someone ( Tomás Fernández Löbbe ?) is working on this or planning to work on this, then I can step back / collaborate.
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Please go ahead, I won't have time to continue this week. Since there is big interest for this Jira, I'd suggest to upload patches with all iterations for early review/collaboration

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Please go ahead, I won't have time to continue this week. Since there is big interest for this Jira, I'd suggest to upload patches with all iterations for early review/collaboration
          Hide
          elyograg Shawn Heisey added a comment -

          I'm curious – what kind of timeframe would be required to create new numeric classes, update the examples so the primary fieldTypes are no longer using the deprecated code, and run enough tests to be sure it's all solid? Is it days, or weeks?

          Show
          elyograg Shawn Heisey added a comment - I'm curious – what kind of timeframe would be required to create new numeric classes, update the examples so the primary fieldTypes are no longer using the deprecated code, and run enough tests to be sure it's all solid? Is it days, or weeks?
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          I'm assuming weeks. There are some issues that we need to figure out how to get around, e.g. LUCENE-7096, LUCENE-7086.
          If the patch in LUCENE-7096 is committed, the patch here will be broken due to Maybe we should revert the single-valued points support as well?. I am thinking on ways to proceed if/once that happens.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - I'm assuming weeks. There are some issues that we need to figure out how to get around, e.g. LUCENE-7096 , LUCENE-7086 . If the patch in LUCENE-7096 is committed, the patch here will be broken due to Maybe we should revert the single-valued points support as well? . I am thinking on ways to proceed if/once that happens.
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Here is a new patch, updated to master. Added tests for docValues actions (faceting, sorting and stats). Still full of commented out code and only int fields yet

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Here is a new patch, updated to master. Added tests for docValues actions (faceting, sorting and stats). Still full of commented out code and only int fields yet
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          New patch:

          • Added some errors when using point fields for unsupported cases (e.g. when faceting on a point field with no doc values). For now I'm considering those bad requests, but I don't know if we'll be able to consider all invalid cases and error gracefully, cases like FunctionQueries may not be easy (currently for faceting on a function query that has a point field with no DV will be a 500 for example, and the error is an IllegalStateException by Lucene).
          • Grouping still doesn't work with PointFields.
          • Added some more test coverage by making the test schema.xml use point fields. I plan to also add this to other test schemas when applicable. Ideally tests would randomly use "Legacy" or "Point" when dv=true
          • Since field boost is not supported, right now I'm throwing an exception if used, but this makes index-time document boosting practically useless, so I think I should change the exception to a log message only and just omit the boost.
          • Still only for int fields, lots of nocommits and a code refactor required
          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - New patch: Added some errors when using point fields for unsupported cases (e.g. when faceting on a point field with no doc values). For now I'm considering those bad requests, but I don't know if we'll be able to consider all invalid cases and error gracefully, cases like FunctionQueries may not be easy (currently for faceting on a function query that has a point field with no DV will be a 500 for example, and the error is an IllegalStateException by Lucene). Grouping still doesn't work with PointFields. Added some more test coverage by making the test schema.xml use point fields. I plan to also add this to other test schemas when applicable. Ideally tests would randomly use "Legacy" or "Point" when dv=true Since field boost is not supported, right now I'm throwing an exception if used, but this makes index-time document boosting practically useless, so I think I should change the exception to a log message only and just omit the boost. Still only for int fields, lots of nocommits and a code refactor required
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Added support and tests for multi valued int fields. Tests still need a lot of work.

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Added support and tests for multi valued int fields. Tests still need a lot of work.
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Patch updated

          • Added more tests.
          • Fixed bugs in multi-valued fields support
          • No longer throwing an exception in case of boosts on the point field, logging on trace level instead.
          • Grouping is still not supported
          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Patch updated Added more tests. Fixed bugs in multi-valued fields support No longer throwing an exception in case of boosts on the point field, logging on trace level instead. Grouping is still not supported
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Minor improvement. Modified also schema11.xml to use point fields, since it's used by many tests. Tests are passing reliably in general. Exceptions are grouping and ExpandComponent. Since those different use cases and code paths I'm not going to tackle them in this Jira. My plan now is to add other field types

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Minor improvement. Modified also schema11.xml to use point fields, since it's used by many tests. Tests are passing reliably in general. Exceptions are grouping and ExpandComponent. Since those different use cases and code paths I'm not going to tackle them in this Jira. My plan now is to add other field types
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Updated title to reflect the discussion and the work being done

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Updated title to reflect the discussion and the work being done
          Hide
          jpountz Adrien Grand added a comment -
          +//    nocommit: Remove this wrap
          +//    if (getFieldInfos().hasPointValues()) {
          +//      throw new IllegalArgumentException("cannot wrap points");
          +//    }
          

          Now that SlowCompositeReaderWrapper is Solr-specific, I think it would be fine to remove this check and move th exception to #getPointValues. That should fix the problem?

          Show
          jpountz Adrien Grand added a comment - + // nocommit: Remove this wrap + // if (getFieldInfos().hasPointValues()) { + // throw new IllegalArgumentException( "cannot wrap points" ); + // } Now that SlowCompositeReaderWrapper is Solr-specific, I think it would be fine to remove this check and move th exception to #getPointValues. That should fix the problem?
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Updated patch.

          • Updated to master.
          • Added DoublePointField.
          • Refactored TestPointFields to accommodate better different PointField types, should be easier to add the next types.
          • Added annotation to suppress point fields in tests (this depends really depends on the schema at this point, not sure if there is a better way)
          • Removed the nocommit from SlowCompositeReaderWrapper
            There are some tests failing, I'll be looking into those next
          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Updated patch. Updated to master. Added DoublePointField . Refactored TestPointFields to accommodate better different PointField types, should be easier to add the next types. Added annotation to suppress point fields in tests (this depends really depends on the schema at this point, not sure if there is a better way) Removed the nocommit from SlowCompositeReaderWrapper There are some tests failing, I'll be looking into those next
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          I just created a branch jira/solr-8396 with the latest patch. With this patch AtomicUpdates are failing, I'm going to look at that now.

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - I just created a branch jira/solr-8396 with the latest patch. With this patch AtomicUpdates are failing, I'm going to look at that now.
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment - - edited

          After talking with Adrien, and later with some more people at the Lucene Revolution, the plan is that PointFields will use SortedNumericDocValues instead of SortedSetDocValues for multi-valued cases. Doing that involves much more work, since we need to change all the consumers. This patch is already getting large, so I think it may be better to tackle that in a followup Jira.
          In the recent branch commits:

          • I removed the use of SortedSetDocValues from the PointFields and I throw an exception if the user tries to create a PointField with MultiValued DV (I'm now ignoring the tests which required MV fields with DV).
          • I fixed the issue with returning DV as stored fields that I was hitting.
          • Added LongPointField.

          Steve Rowe had some concerns about naming, since Solr already has a PointType and in the schemas I'm using "pTYPE", which could be confused with the old "Plain numeric fields" (Solr 1.4-ish?). I'm open to suggestions.

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - - edited After talking with Adrien, and later with some more people at the Lucene Revolution, the plan is that PointFields will use SortedNumericDocValues instead of SortedSetDocValues for multi-valued cases. Doing that involves much more work, since we need to change all the consumers. This patch is already getting large, so I think it may be better to tackle that in a followup Jira. In the recent branch commits: I removed the use of SortedSetDocValues from the PointFields and I throw an exception if the user tries to create a PointField with MultiValued DV (I'm now ignoring the tests which required MV fields with DV). I fixed the issue with returning DV as stored fields that I was hitting. Added LongPointField. Steve Rowe had some concerns about naming, since Solr already has a PointType and in the schemas I'm using "pTYPE", which could be confused with the old "Plain numeric fields" (Solr 1.4-ish?). I'm open to suggestions.
          Hide
          dsmiley David Smiley added a comment -

          the plan is that PointFields will use SortedNumericDocValues instead of SortedSetDocValues for multi-valued cases. Doing that involves much more work, since we need to change all the consumers. This patch is already getting large, so I think it may be better to tackle that in a followup Jira.

          Yes; definitely a separate issue... it doesn't seem related to this issue as this issue is about the index structure (value/range -> docs) not the doc value (doc -> value).

          Show
          dsmiley David Smiley added a comment - the plan is that PointFields will use SortedNumericDocValues instead of SortedSetDocValues for multi-valued cases. Doing that involves much more work, since we need to change all the consumers. This patch is already getting large, so I think it may be better to tackle that in a followup Jira. Yes; definitely a separate issue... it doesn't seem related to this issue as this issue is about the index structure (value/range -> docs) not the doc value (doc -> value).
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          The docvalues format is heavily related when looking at the larger picture (i.e. from the user perspective, we're creating a new numeric field type as a whole).
          Different JIRAs or not doesn't matter... what does matter is if points are released/exposed in an official release with the old docvalues format. That definitely impacts future support, back compat, interfaces, etc.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - The docvalues format is heavily related when looking at the larger picture (i.e. from the user perspective, we're creating a new numeric field type as a whole). Different JIRAs or not doesn't matter... what does matter is if points are released/exposed in an official release with the old docvalues format. That definitely impacts future support, back compat, interfaces, etc.
          Hide
          dsmiley David Smiley added a comment -

          Is anything changing with DocValues in this issue? i.e. if I went from LongTrieField -> LongPointField (or whatever the naming is) as proposed in this issue and I hypothetically had index=false but docValues=true, then is there any real change? I anticipate none.

          Show
          dsmiley David Smiley added a comment - Is anything changing with DocValues in this issue? i.e. if I went from LongTrieField -> LongPointField (or whatever the naming is) as proposed in this issue and I hypothetically had index=false but docValues=true, then is there any real change? I anticipate none.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          Is anything changing with DocValues in this issue?

          Yes, see Tomas's previous comment:

          the plan is that PointFields will use SortedNumericDocValues

          It doesn't matter so much if all of this gets done in 2 commits/issues or 10, but we should know where we're going and how we want to get there.

          Actually, I just saw the comment from Tomas that addresses the most important part: "I throw an exception if the user tries to create a PointField with MultiValued DV". So this nicely handles the concern about mixed DV types with point fields (sometimes SortedSetDocValues, sometimes SortedNumericDocValues).

          Show
          yseeley@gmail.com Yonik Seeley added a comment - Is anything changing with DocValues in this issue? Yes, see Tomas's previous comment: the plan is that PointFields will use SortedNumericDocValues It doesn't matter so much if all of this gets done in 2 commits/issues or 10, but we should know where we're going and how we want to get there. Actually, I just saw the comment from Tomas that addresses the most important part: "I throw an exception if the user tries to create a PointField with MultiValued DV". So this nicely handles the concern about mixed DV types with point fields (sometimes SortedSetDocValues, sometimes SortedNumericDocValues).
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          Steve Rowe had some concerns about naming, since Solr already has a PointType and in the schemas I'm using "pTYPE", which could be confused with the old "Plain numeric fields" (Solr 1.4-ish?).

          The first time we went through this transition, "int" was renamed to "pint" in the example schema, and then a new "int" was created to use trie (numeric).
          If we expect the old numerics to go away at some point, we could do the same thing. In the longer run, keeping simple names like "int" for our primary types is nice.
          If we're taking a more phased approach though, we might want to wait until point fields work with more stuff before rename.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - Steve Rowe had some concerns about naming, since Solr already has a PointType and in the schemas I'm using "pTYPE", which could be confused with the old "Plain numeric fields" (Solr 1.4-ish?). The first time we went through this transition, "int" was renamed to "pint" in the example schema, and then a new "int" was created to use trie (numeric). If we expect the old numerics to go away at some point, we could do the same thing. In the longer run, keeping simple names like "int" for our primary types is nice. If we're taking a more phased approach though, we might want to wait until point fields work with more stuff before rename.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          Steve Rowe had some concerns about naming, since Solr already has a PointType and in the schemas I'm using "pTYPE", which could be confused with the old "Plain numeric fields" (Solr 1.4-ish?).

          The first time we went through this transition, "int" was renamed to "pint" in the example schema, and then a new "int" was created to use trie (numeric).
          If we expect the old numerics to go away at some point, we could do the same thing. In the longer run, keeping simple names like "int" for our primary types is nice.
          If we're taking a more phased approach though, we might want to wait until point fields work with more stuff before rename.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - Steve Rowe had some concerns about naming, since Solr already has a PointType and in the schemas I'm using "pTYPE", which could be confused with the old "Plain numeric fields" (Solr 1.4-ish?). The first time we went through this transition, "int" was renamed to "pint" in the example schema, and then a new "int" was created to use trie (numeric). If we expect the old numerics to go away at some point, we could do the same thing. In the longer run, keeping simple names like "int" for our primary types is nice. If we're taking a more phased approach though, we might want to wait until point fields work with more stuff before rename.
          Hide
          dsmiley David Smiley added a comment -

          Phased approach makes sense... I think the first release exposing this feature should be opt-in. For this release, we could declare them with 'p'. Since it's been ages since that was a prefix in our schemas (for plain numeric), I think it's fine. "bkd" is an alternative.

          Yes I did read the SortedNumericDocValues vs SortedSetDocValues for multi-valued... I meant otherwise/in addition to that. I think it should be a separate issue... and perhaps we should wait on backporting this issue until both together can be landed on the 6x line to ensure they happen on the same release – I get your concern there.

          Show
          dsmiley David Smiley added a comment - Phased approach makes sense... I think the first release exposing this feature should be opt-in. For this release, we could declare them with 'p'. Since it's been ages since that was a prefix in our schemas (for plain numeric), I think it's fine. "bkd" is an alternative. Yes I did read the SortedNumericDocValues vs SortedSetDocValues for multi-valued... I meant otherwise/in addition to that. I think it should be a separate issue... and perhaps we should wait on backporting this issue until both together can be landed on the 6x line to ensure they happen on the same release – I get your concern there.
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          i.e. if I went from LongTrieField -> LongPointField (or whatever the naming is) as proposed in this issue and I hypothetically had index=false but docValues=true, then is there any real change?

          For single value the DV implementation is the same. For MultiValue not. As I said, the plan now is to change the implementation to SortedNumeric, but if we decided to keep SortedSet we would probably change the encoding from prefix (in LegacyNumericUtils) to the sortable bytes encoding Points use (in NumericUtils).

          The first time we went through this transition, "int" was renamed to "pint" in the example schema, and then a new "int" was created to use trie (numeric)....

          Yes, with this patch I would add the "pTYPE" with PointField to the basic schemas. Once we are comfortable with them we can switch the "TYPE" fields to use PointFields too, that would be changing the default for Solr (although there may be more tasks involved there)

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - i.e. if I went from LongTrieField -> LongPointField (or whatever the naming is) as proposed in this issue and I hypothetically had index=false but docValues=true, then is there any real change? For single value the DV implementation is the same. For MultiValue not. As I said, the plan now is to change the implementation to SortedNumeric, but if we decided to keep SortedSet we would probably change the encoding from prefix (in LegacyNumericUtils ) to the sortable bytes encoding Points use (in NumericUtils ). The first time we went through this transition, "int" was renamed to "pint" in the example schema, and then a new "int" was created to use trie (numeric).... Yes, with this patch I would add the "pTYPE" with PointField to the basic schemas. Once we are comfortable with them we can switch the "TYPE" fields to use PointFields too, that would be changing the default for Solr (although there may be more tasks involved there)
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          I haven't tested it, but SOLR-9786 should cause the query parser to automatically delegate to FieldType.getSetQuery() for queries on more than one point (for example q=my_point_field:(20 5 10 15 23))

          Show
          yseeley@gmail.com Yonik Seeley added a comment - I haven't tested it, but SOLR-9786 should cause the query parser to automatically delegate to FieldType.getSetQuery() for queries on more than one point (for example q=my_point_field:(20 5 10 15 23))
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Uploading a patch updated to current master. I think it’s mostly done, so this is a good time to review if you are interested in the feature. I plan to commit to master soon and let it bake there some time before moving to branch 6_x. There are no big issues with compatibility so I think it should be fine to backport at some point. The last changes are not in the branch, I’m trying to avoid an avalanche of “commit emails” and possibly updates to Jiras due to the recent merge, so please review the patch. I’m leaving some tasks for followup Jiras that can be fixed/discussed separately:

          • LukeRequestHandler doesn’t populate docFreq for PointFields
          • Implement DatePointField
          • Implement support for MV DocValues in PointFields
          • Add method toInternalByteRef to FieldType and possibly deprecate toInternal()
          • Add support for PointFields in FacetModule (JSON Facets)
          • Add PointFields as pField in example schemas
          • Add support for facet method “fc” with PointFields (only “FCS” is currently supported for field faceting)
          • Add support for grouping with PointFIelds
          • Add support for pivot faceting with PointFields
          • Add support for ExpandComponent with PointFIelds
          • Add support for CollapseQParser with PointFields

          ...SOLR-9786 should cause the query parser to automatically delegate to FieldType.getSetQuery() for queries on more than one point (

          Great. I had added a getSetQuery method in PointField class, I removed it and I’m now using super’s (implemented in the different Point FieldType classes). Also added validation in TestSolrQueryParser.java

          The first time we went through this transition, "int" was renamed to "pint" in the example schema, and then a new "int" was created to use trie (numeric)….

          +1. But in any case, since I’m leaving the changes to the example schema.xml out of this patch, this can be further discussed in followup Jira if anyone has concerns with the approach.

          Not sure if the “solr.tests.preferPointFields” changes I did are implemented in the correct way, I’ll review that before committing. Feel free to comment on that too.

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Uploading a patch updated to current master. I think it’s mostly done, so this is a good time to review if you are interested in the feature. I plan to commit to master soon and let it bake there some time before moving to branch 6_x. There are no big issues with compatibility so I think it should be fine to backport at some point. The last changes are not in the branch, I’m trying to avoid an avalanche of “commit emails” and possibly updates to Jiras due to the recent merge, so please review the patch. I’m leaving some tasks for followup Jiras that can be fixed/discussed separately: LukeRequestHandler doesn’t populate docFreq for PointFields Implement DatePointField Implement support for MV DocValues in PointFields Add method toInternalByteRef to FieldType and possibly deprecate toInternal() Add support for PointFields in FacetModule (JSON Facets) Add PointFields as pField in example schemas Add support for facet method “fc” with PointFields (only “FCS” is currently supported for field faceting) Add support for grouping with PointFIelds Add support for pivot faceting with PointFields Add support for ExpandComponent with PointFIelds Add support for CollapseQParser with PointFields ... SOLR-9786 should cause the query parser to automatically delegate to FieldType.getSetQuery() for queries on more than one point ( Great. I had added a getSetQuery method in PointField class, I removed it and I’m now using super’s (implemented in the different Point FieldType classes). Also added validation in TestSolrQueryParser.java The first time we went through this transition, "int" was renamed to "pint" in the example schema, and then a new "int" was created to use trie (numeric)…. +1. But in any case, since I’m leaving the changes to the example schema.xml out of this patch, this can be further discussed in followup Jira if anyone has concerns with the approach. Not sure if the “solr.tests.preferPointFields” changes I did are implemented in the correct way, I’ll review that before committing. Feel free to comment on that too.
          Hide
          jpountz Adrien Grand added a comment -

          It is a pity we have to add that many calls to isPointField() but I don't have a better idea and I think it is nice how you emit explicit errors eg. when users try to sort on a point field that does not have doc values. Otherwise the change looks good, I focused on the point types and the way you generate eg. range queries using *Point.nextDown/nextUp looked good.

          One suggestion for a simplification: in the below change, it looks like the logic that you apply to point fields would work in the general case and be as efficient?

          +    if (ft.isPointField()) {
          +      for (String term : terms) {
          +        int count = searcher.numDocs(ft.getFieldQuery(null, sf, term), parsed.docs);
          +        res.add(term, count);
          +      }
          +    } else {
          +      for (String term : terms) {
          +        String internal = ft.toInternal(term);
          +        int count = searcher.numDocs(new TermQuery(new Term(field, internal)), parsed.docs);
          +        res.add(term, count);
          +      }
               }
          
          Show
          jpountz Adrien Grand added a comment - It is a pity we have to add that many calls to isPointField() but I don't have a better idea and I think it is nice how you emit explicit errors eg. when users try to sort on a point field that does not have doc values. Otherwise the change looks good, I focused on the point types and the way you generate eg. range queries using *Point.nextDown/nextUp looked good. One suggestion for a simplification: in the below change, it looks like the logic that you apply to point fields would work in the general case and be as efficient? + if (ft.isPointField()) { + for ( String term : terms) { + int count = searcher.numDocs(ft.getFieldQuery( null , sf, term), parsed.docs); + res.add(term, count); + } + } else { + for ( String term : terms) { + String internal = ft.toInternal(term); + int count = searcher.numDocs( new TermQuery( new Term(field, internal)), parsed.docs); + res.add(term, count); + } }
          Hide
          jpountz Adrien Grand added a comment -

          Maybe someone more familiar with Solr should have a look too but I think this is a good start, I'm +1 to push this and iterate from here.

          Show
          jpountz Adrien Grand added a comment - Maybe someone more familiar with Solr should have a look too but I think this is a good start, I'm +1 to push this and iterate from here.
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Thanks for the review Adrien.

          It is a pity we have to add that many calls to isPointField()

          Agree. Some of those will be eventually removed, like the ones that prevent not supported features or where we are calling toInternalByteRef(...). In part that's why I propose we deprecate toInternal(...) in favor of toInternalByteRef(...).

          One suggestion for a simplification:

          That's a good idea, but since I don't know what all the FieldType.getFieldQuery(...) implementations are doing I'd prefer to leave that to a different Jira. I've been running tests with the current patch for some time and I've seen no related issues

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Thanks for the review Adrien. It is a pity we have to add that many calls to isPointField() Agree. Some of those will be eventually removed, like the ones that prevent not supported features or where we are calling toInternalByteRef(...) . In part that's why I propose we deprecate toInternal(...) in favor of toInternalByteRef(...) . One suggestion for a simplification: That's a good idea, but since I don't know what all the FieldType.getFieldQuery(...) implementations are doing I'd prefer to leave that to a different Jira. I've been running tests with the current patch for some time and I've seen no related issues
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Here is my final patch, with some minor changes.

          • Modified some more test schemas to use points (a couple were it was obvious when DV were needed and when not).
          • Modified TestRandomFacetDV to also test PointFields
          • Moved TestPointFields to schema package
          • Cleanup tests
          • Added some javadoc and fixed precommit
            I’ll commit this and create Jiras for followup tasks.
          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Here is my final patch, with some minor changes. Modified some more test schemas to use points (a couple were it was obvious when DV were needed and when not). Modified TestRandomFacetDV to also test PointFields Moved TestPointFields to schema package Cleanup tests Added some javadoc and fixed precommit I’ll commit this and create Jiras for followup tasks.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          I’ll commit this and create Jiras for followup tasks.

          +1 to committing this and fix things, if any, later. Exciting!

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - I’ll commit this and create Jiras for followup tasks. +1 to committing this and fix things, if any, later. Exciting!
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 57934ba4480d71218c7f60d0417dbae9d26188d0 in lucene-solr's branch refs/heads/master from Tomas Fernandez Lobbe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=57934ba ]

          SOLR-8396: Add support for PointFields in Solr

          Show
          jira-bot ASF subversion and git services added a comment - Commit 57934ba4480d71218c7f60d0417dbae9d26188d0 in lucene-solr's branch refs/heads/master from Tomas Fernandez Lobbe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=57934ba ] SOLR-8396 : Add support for PointFields in Solr
          Hide
          dsmiley David Smiley added a comment -

          Yay; thanks so much Tomás!

          Show
          dsmiley David Smiley added a comment - Yay; thanks so much Tomás!
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Tomás Fernández Löbbe, are you planning to backport now? AFAICT, this is stable and tests are passing fine.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Tomás Fernández Löbbe , are you planning to backport now? AFAICT, this is stable and tests are passing fine.
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          I was thinking in waiting to have some of the followup tasks before backporting (MultiValue field DV support for example), but I'm open to suggestions.

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - I was thinking in waiting to have some of the followup tasks before backporting (MultiValue field DV support for example), but I'm open to suggestions.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 59c41e2a6c685dd9ac943c69d12e9bfe2a7d380e in lucene-solr's branch refs/heads/master from Tomas Fernandez Lobbe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=59c41e2 ]

          SOLR-10011: Add NumberType getNumberType() to FieldType and deprecate LegacyNumericType getNumericType()

          Modify references to getNumericType() to use the new getNumberType(). NumberType is shared for the different numeric implementations supported in Solr (TrieFields and PointFields).
          CC SOLR-8396

          Show
          jira-bot ASF subversion and git services added a comment - Commit 59c41e2a6c685dd9ac943c69d12e9bfe2a7d380e in lucene-solr's branch refs/heads/master from Tomas Fernandez Lobbe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=59c41e2 ] SOLR-10011 : Add NumberType getNumberType() to FieldType and deprecate LegacyNumericType getNumericType() Modify references to getNumericType() to use the new getNumberType(). NumberType is shared for the different numeric implementations supported in Solr (TrieFields and PointFields). CC SOLR-8396
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          I was thinking in waiting to have some of the followup tasks before backporting (MultiValue field DV support for example), but I'm open to suggestions.

          I uploaded a patch to SOLR-9987. I plan to commit it soon (probably tomorrow) and backport to 6.x

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - I was thinking in waiting to have some of the followup tasks before backporting (MultiValue field DV support for example), but I'm open to suggestions. I uploaded a patch to SOLR-9987 . I plan to commit it soon (probably tomorrow) and backport to 6.x
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 7dcf9de41f6435a741910a6367ef9fece11a588b in lucene-solr's branch refs/heads/master from Tomas Fernandez Lobbe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7dcf9de ]

          SOLR-9987: Implement support for multi-valued DocValues in PointFields
          CC SOLR-8396

          Show
          jira-bot ASF subversion and git services added a comment - Commit 7dcf9de41f6435a741910a6367ef9fece11a588b in lucene-solr's branch refs/heads/master from Tomas Fernandez Lobbe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7dcf9de ] SOLR-9987 : Implement support for multi-valued DocValues in PointFields CC SOLR-8396
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Just committed the changes for SOLR-9987.
          I’ll now backport the following commits from master

          57934ba4480d71218c7f60d0417dbae9d26188d0 SOLR-8396: Add support for PointFields in Solr
          285a1013ad04dd1cd5e5e41ffa93a87fe862c152 SOLR-10011: Refactor PointField & TrieField to now have a common base class, NumericFieldType
          0f7990b2c8590d169add59354cc2678260f94e03 SOLR-10011: Fix exception log message
          59c41e2a6c685dd9ac943c69d12e9bfe2a7d380e SOLR-10011: Add NumberType getNumberType() to FieldType and deprecate LegacyNumericType getNumericType()
          7dcf9de41f6435a741910a6367ef9fece11a588b SOLR-9987: Implement support for multi-valued DocValues in PointFields

          I’ll also move the CHANGES entries from from 7 to 6.5

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Just committed the changes for SOLR-9987 . I’ll now backport the following commits from master 57934ba4480d71218c7f60d0417dbae9d26188d0 SOLR-8396 : Add support for PointFields in Solr 285a1013ad04dd1cd5e5e41ffa93a87fe862c152 SOLR-10011 : Refactor PointField & TrieField to now have a common base class, NumericFieldType 0f7990b2c8590d169add59354cc2678260f94e03 SOLR-10011 : Fix exception log message 59c41e2a6c685dd9ac943c69d12e9bfe2a7d380e SOLR-10011 : Add NumberType getNumberType() to FieldType and deprecate LegacyNumericType getNumericType() 7dcf9de41f6435a741910a6367ef9fece11a588b SOLR-9987 : Implement support for multi-valued DocValues in PointFields I’ll also move the CHANGES entries from from 7 to 6.5
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit b92e318dc929defc5d100d82704898e834510265 in lucene-solr's branch refs/heads/branch_6x from Tomas Fernandez Lobbe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b92e318 ]

          SOLR-8396: Add support for PointFields in Solr

          Show
          jira-bot ASF subversion and git services added a comment - Commit b92e318dc929defc5d100d82704898e834510265 in lucene-solr's branch refs/heads/branch_6x from Tomas Fernandez Lobbe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b92e318 ] SOLR-8396 : Add support for PointFields in Solr
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit c27880e332722e992294e05749b63300d3eaab44 in lucene-solr's branch refs/heads/branch_6x from Tomas Fernandez Lobbe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c27880e ]

          SOLR-10011: Add NumberType getNumberType() to FieldType and deprecate LegacyNumericType getNumericType()

          Modify references to getNumericType() to use the new getNumberType(). NumberType is shared for the different numeric implementations supported in Solr (TrieFields and PointFields).
          CC SOLR-8396

          Show
          jira-bot ASF subversion and git services added a comment - Commit c27880e332722e992294e05749b63300d3eaab44 in lucene-solr's branch refs/heads/branch_6x from Tomas Fernandez Lobbe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c27880e ] SOLR-10011 : Add NumberType getNumberType() to FieldType and deprecate LegacyNumericType getNumericType() Modify references to getNumericType() to use the new getNumberType(). NumberType is shared for the different numeric implementations supported in Solr (TrieFields and PointFields). CC SOLR-8396
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit bc10fa67b641d0cfb9bd1954378019d4fc343ae8 in lucene-solr's branch refs/heads/branch_6x from Tomas Fernandez Lobbe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bc10fa6 ]

          SOLR-9987: Implement support for multi-valued DocValues in PointFields
          CC SOLR-8396

          Show
          jira-bot ASF subversion and git services added a comment - Commit bc10fa67b641d0cfb9bd1954378019d4fc343ae8 in lucene-solr's branch refs/heads/branch_6x from Tomas Fernandez Lobbe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bc10fa6 ] SOLR-9987 : Implement support for multi-valued DocValues in PointFields CC SOLR-8396
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 81b4288a2133dce87e0ac92da5f6e37dc28176f6 in lucene-solr's branch refs/heads/branch_6x from Tomas Fernandez Lobbe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=81b4288 ]

          SOLR-8396, SOLR-9987, SOLR-10011: Move CHANGES entries from 7.0 to 6.5

          Show
          jira-bot ASF subversion and git services added a comment - Commit 81b4288a2133dce87e0ac92da5f6e37dc28176f6 in lucene-solr's branch refs/heads/branch_6x from Tomas Fernandez Lobbe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=81b4288 ] SOLR-8396 , SOLR-9987 , SOLR-10011 : Move CHANGES entries from 7.0 to 6.5
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 796da187d28c8426cbc60b13808e775bf95a93d2 in lucene-solr's branch refs/heads/branch_6x from Tomas Fernandez Lobbe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=796da18 ]

          SOLR-8396: Fix compile issues after merge

          Show
          jira-bot ASF subversion and git services added a comment - Commit 796da187d28c8426cbc60b13808e775bf95a93d2 in lucene-solr's branch refs/heads/branch_6x from Tomas Fernandez Lobbe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=796da18 ] SOLR-8396 : Fix compile issues after merge
          Hide
          tomasflobbe Tomás Fernández Löbbe added a comment -

          Resolving this Jira since the main work is done. Followup work can be done in related Jiras

          Show
          tomasflobbe Tomás Fernández Löbbe added a comment - Resolving this Jira since the main work is done. Followup work can be done in related Jiras

            People

            • Assignee:
              tomasflobbe Tomás Fernández Löbbe
              Reporter:
              ichattopadhyaya Ishan Chattopadhyaya
            • Votes:
              2 Vote for this issue
              Watchers:
              23 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development