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

Export handler returns zero for numeric fields that are not in the original doc

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.4, 7.0
    • Component/s: None
    • Labels:
      None

      Description

      From the dev list discussion:

      My original post.
      Zero is different from not
      existing. And let's claim that I want to process a stream and, say,
      facet on in integer field over the result set. There's no way on the
      client side to distinguish between a document that has a zero in the
      field and one that didn't have the field in the first place so I'll
      over-count the zero bucket.

      From Dennis Gove:
      Is this true for non-numeric fields as well? I agree that this seems like a very bad thing.

      I can't imagine that a fix would cause a problem with Streaming Expressions, ParallelSQL, or other given that the /select handler is not returning 0 for these missing fields (the /select handler is the default handler for the Streaming API so if nulls were a problem I imagine we'd have already seen it).

      That said, within Streaming Expressions there is a select(...) function which supports a replace(...) operation which allows you to replace one value (or null) with some other value. If a 0 were necessary one could use a select(...) to replace null with 0 using an expression like this
      select(<stream>, replace(fieldA, null, withValue=0)).
      The end result of that would be that the field fieldA would never have a null value and for all tuples where a null value existed it would be replaced with 0.

      Details on the select function can be found at https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61330338#StreamingExpressions-select.

      And to answer Denis' question, null gets returned for string DocValues fields.

      1. SOLR-9166.patch
        14 kB
        Erick Erickson
      2. SOLR-9166.patch
        13 kB
        Erick Erickson
      3. SOLR-9166.patch
        27 kB
        Erick Erickson
      4. SOLR-9166.patch
        2 kB
        Erick Erickson
      5. SOLR-9166-6x.patch
        14 kB
        Erick Erickson

        Issue Links

          Activity

          Hide
          erickerickson Erick Erickson added a comment -

          From Joel on the dev list.

          Yes, the /export handler returns zero for numeric fields that aren't present. String fields should be empty though if not present.

          We'll want to keep the zero while sorting in the /export handler. But removing the zero when outputing the field should by OK. We'll just need to add test cases that cover the numeric nulls. The RollupStream would be one place that might have a problem with this.

          Also, there may be other client applications that rely on the current behavior. So possibly adding a switch on the export handler for numeric nulls is the safest approach.

          Show
          erickerickson Erick Erickson added a comment - From Joel on the dev list. Yes, the /export handler returns zero for numeric fields that aren't present. String fields should be empty though if not present. We'll want to keep the zero while sorting in the /export handler. But removing the zero when outputing the field should by OK. We'll just need to add test cases that cover the numeric nulls. The RollupStream would be one place that might have a problem with this. Also, there may be other client applications that rely on the current behavior. So possibly adding a switch on the export handler for numeric nulls is the safest approach.
          Hide
          erickerickson Erick Erickson added a comment -

          Right, I'm looking at the code in SortingResponseWriter so I think that would handle the issue of sorting etc., just not writing it to the return doc at the very last second. I have no clue what the implications are for the code that processes analytics on the worker nodes for instance, we'll just have to harden that I suppose.

          As far as a switch is concerned, I'm torn. I think current behavior is surprising and would like to see people who need current behavior have to do something special rather than someone expecting what I think is correct behavior do something special. I guess we can argue "correct", but you get the idea....

          To be consistent it should work the same way for both strings and numerics.

          So even though it would be a change in behavior for current users, I'd propose two properties. The default behavior if neither is specified would be to not return anything in the tuple for absent strings or absent numerics.

          returnZeroForMissingNumerics=true would do what happens now, zero gets returned for missing numeric fields Otherwise do not return the field in the tuple (default false) .

          returnEmptyForMissingStrings=true would return the field with "" rather than not returning the field in the tuple (default false)

          BTW, I assigned this to myself to not lose track of it, if anyone wants to jump in feel free....

          Show
          erickerickson Erick Erickson added a comment - Right, I'm looking at the code in SortingResponseWriter so I think that would handle the issue of sorting etc., just not writing it to the return doc at the very last second. I have no clue what the implications are for the code that processes analytics on the worker nodes for instance, we'll just have to harden that I suppose. As far as a switch is concerned, I'm torn. I think current behavior is surprising and would like to see people who need current behavior have to do something special rather than someone expecting what I think is correct behavior do something special. I guess we can argue "correct", but you get the idea.... To be consistent it should work the same way for both strings and numerics. So even though it would be a change in behavior for current users, I'd propose two properties. The default behavior if neither is specified would be to not return anything in the tuple for absent strings or absent numerics. returnZeroForMissingNumerics=true would do what happens now, zero gets returned for missing numeric fields Otherwise do not return the field in the tuple (default false) . returnEmptyForMissingStrings=true would return the field with "" rather than not returning the field in the tuple (default false) BTW, I assigned this to myself to not lose track of it, if anyone wants to jump in feel free....
          Hide
          erickerickson Erick Erickson added a comment -

          Trivial test illustrating the behavior, no fix. We'll have to beef up the tests a lot more than this though.

          Show
          erickerickson Erick Erickson added a comment - Trivial test illustrating the behavior, no fix. We'll have to beef up the tests a lot more than this though.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          We'll want to keep the zero while sorting in the /export handler.

          I'd rather think that missing should sort before or after existing values (same as /select). Sorting missing in the middle of real values (assuming the presence of negative values) is odd.

          I think current behavior is surprising and would like to see people who need current behavior have to do something special rather than someone expecting what I think is correct behavior do something special.

          +1

          If one wants 0 in place of "missing", perhaps existing syntax could be used to specify the default:
          fl=def(my_numeric_field,0)

          Show
          yseeley@gmail.com Yonik Seeley added a comment - We'll want to keep the zero while sorting in the /export handler. I'd rather think that missing should sort before or after existing values (same as /select). Sorting missing in the middle of real values (assuming the presence of negative values) is odd. I think current behavior is surprising and would like to see people who need current behavior have to do something special rather than someone expecting what I think is correct behavior do something special. +1 If one wants 0 in place of "missing", perhaps existing syntax could be used to specify the default: fl=def(my_numeric_field,0)
          Hide
          erickerickson Erick Erickson added a comment -

          Rohit I had some time today so started this patch.

          What I have so far. I got it this far and ran into a few things I thought I'd run by folks. Lots of nocommits and the like currently, as well as new failing tests. But it's progress....

          Yonik Seeley Joel Bernstein Dennis Gove I'd be particularly interested in your takes.

          1> My base assumption is that sorting during export should return docs in the same order as using the /select handler. Currently this doesn't happen, the new test I wrote fails all over the place. Not quite sure why, but I just got all this to semi-work so I'm checkpointing.

          2> I want to fold the two parameters into a single on/off returnDefaultsForMissing which defaults to "false". This would mean there's really no way to get the old behavior where numerics return zero and strings return null. Is that OK? I think it's easier to explain something like "defaults for numerics are zero, default for string is "", default for boolean is "false" and default for date is in 1970". But see <4>.

          3> Does it make any sense to support sortMissingFirst/Last? My initial take is "no" since what matters is consistent sorting. That said I started down that road before wondering whether it was desirable so this patch has sortMissingFirstLast in the test, it'll be removed unless there are objections.

          4> Yonik Seeley: Your comment about using functions is interesting. I'll take a look at that now that I have a clue what the problem is. It's certainly more elegant than some new flag I think and allows the user to put anything at all in rather than us deciding what a "proper" default is. Do you have any advice on how to access the defined default for the fields in SortingResponseWriter since that's where I need to trap this? (being lazy here).

          5> I @Ignored all the rest of the tests except the new one to be able to beast the new stuff, they'll be un-ignored before committing.

          6> Despite my comment on the dev list, after looking into this I don't think we want to force it into 6.3, I think there'll be some ramifications we'll need to bake out.

          No doubt more later when we get some advice on how to continue.

          Show
          erickerickson Erick Erickson added a comment - Rohit I had some time today so started this patch. What I have so far. I got it this far and ran into a few things I thought I'd run by folks. Lots of nocommits and the like currently, as well as new failing tests. But it's progress.... Yonik Seeley Joel Bernstein Dennis Gove I'd be particularly interested in your takes. 1> My base assumption is that sorting during export should return docs in the same order as using the /select handler. Currently this doesn't happen, the new test I wrote fails all over the place. Not quite sure why, but I just got all this to semi-work so I'm checkpointing. 2> I want to fold the two parameters into a single on/off returnDefaultsForMissing which defaults to "false". This would mean there's really no way to get the old behavior where numerics return zero and strings return null. Is that OK? I think it's easier to explain something like "defaults for numerics are zero, default for string is "", default for boolean is "false" and default for date is in 1970". But see <4>. 3> Does it make any sense to support sortMissingFirst/Last? My initial take is "no" since what matters is consistent sorting. That said I started down that road before wondering whether it was desirable so this patch has sortMissingFirstLast in the test, it'll be removed unless there are objections. 4> Yonik Seeley : Your comment about using functions is interesting. I'll take a look at that now that I have a clue what the problem is. It's certainly more elegant than some new flag I think and allows the user to put anything at all in rather than us deciding what a "proper" default is. Do you have any advice on how to access the defined default for the fields in SortingResponseWriter since that's where I need to trap this? (being lazy here). 5> I @Ignored all the rest of the tests except the new one to be able to beast the new stuff, they'll be un-ignored before committing. 6> Despite my comment on the dev list, after looking into this I don't think we want to force it into 6.3, I think there'll be some ramifications we'll need to bake out. No doubt more later when we get some advice on how to continue.
          Hide
          erickerickson Erick Erickson added a comment -

          Yonik Seeley Thinking a bit more about specifying the defaults with the def() function. Much as I hate to say it, I think we should do both. Have hard-coded default values (this JIRA) with the option to override as you suggest on a per-query basis. It seems onerous to require every query to specify the default values when the "standard" defaults may well do.

          So I suggest we complete this JIRA without implementing the def() options and I'll raise a separate JIRA for that as an enhancement. Making no promises to actually implement it mind you

          Show
          erickerickson Erick Erickson added a comment - Yonik Seeley Thinking a bit more about specifying the defaults with the def() function. Much as I hate to say it, I think we should do both. Have hard-coded default values (this JIRA) with the option to override as you suggest on a per-query basis. It seems onerous to require every query to specify the default values when the "standard" defaults may well do. So I suggest we complete this JIRA without implementing the def() options and I'll raise a separate JIRA for that as an enhancement. Making no promises to actually implement it mind you
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          Do we even need returnDefaultsForMissing at all (i.e. what is depending on zeroes for being filled in for missing values?)

          Show
          yseeley@gmail.com Yonik Seeley added a comment - Do we even need returnDefaultsForMissing at all (i.e. what is depending on zeroes for being filled in for missing values?)
          Hide
          joel.bernstein Joel Bernstein added a comment -

          That is the current behavior which people have already coded to. And there may be Streaming classes that break if the fields are null, like the RollupStream.

          Show
          joel.bernstein Joel Bernstein added a comment - That is the current behavior which people have already coded to. And there may be Streaming classes that break if the fields are null, like the RollupStream.
          Hide
          erickerickson Erick Erickson added a comment -

          The only reason I assumed we needed returnDefaultsForMissing was if/when the current behavior was required. I confess I was thinking of it from the installed user-base perspective rather than an internal one.

          Yonik's question made me re-think that though. Let's say we don't return defaults and fix up any Solr code to deal with this properly (don't know if it's possible, just sayin'). In that case would this back-compat break be acceptable? My initial reaction is "no", should support this work-around and perhaps deprecate the behavior and remove it eventually.

          Show
          erickerickson Erick Erickson added a comment - The only reason I assumed we needed returnDefaultsForMissing was if/when the current behavior was required. I confess I was thinking of it from the installed user-base perspective rather than an internal one. Yonik's question made me re-think that though. Let's say we don't return defaults and fix up any Solr code to deal with this properly (don't know if it's possible, just sayin'). In that case would this back-compat break be acceptable? My initial reaction is "no", should support this work-around and perhaps deprecate the behavior and remove it eventually.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          Can't streaming already use /select in some cases? If so, everything already needs to deal with missing values. Everything like RollupStream that can't deal with missing values needs to be fixed anyway?
          But perhaps you meant existing external users of /xport (i.e. not streaming)? I wonder what percent of users with missing values actually depend on that behavior vs unknowingly have broken stats...

          Anyway, if we want to add returnDefaultsForMissing to /xport for those users, I think that's OK. I don't think we should use it ourselves however.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - Can't streaming already use /select in some cases? If so, everything already needs to deal with missing values. Everything like RollupStream that can't deal with missing values needs to be fixed anyway? But perhaps you meant existing external users of /xport (i.e. not streaming)? I wonder what percent of users with missing values actually depend on that behavior vs unknowingly have broken stats... Anyway, if we want to add returnDefaultsForMissing to /xport for those users, I think that's OK. I don't think we should use it ourselves however.
          Hide
          erickerickson Erick Erickson added a comment -

          Right, I was thinking of current /xport users. Or we could just call it a bug in the existing implementation and not support returnDefaultsForMissing. Yeah, that's the ticket.....

          bq: I wonder what percent of users with missing values actually depend on that behavior vs unknowingly have broken stats

          That's my question too.

          Well, maybe we'll gather a bit of data and just pull the returnDefaultsForMisisng out of the patch, run all the unit tests and see what falls out. May have to beef up some of the tests to have some docs with missing values and see what happens.

          Show
          erickerickson Erick Erickson added a comment - Right, I was thinking of current /xport users. Or we could just call it a bug in the existing implementation and not support returnDefaultsForMissing. Yeah, that's the ticket..... bq: I wonder what percent of users with missing values actually depend on that behavior vs unknowingly have broken stats That's my question too. Well, maybe we'll gather a bit of data and just pull the returnDefaultsForMisisng out of the patch, run all the unit tests and see what falls out. May have to beef up some of the tests to have some docs with missing values and see what happens.
          Hide
          erickerickson Erick Erickson added a comment -

          Latest patch implement as we've discussed. The code changes are absolutely minimal but are made in ExportWriter since SortingResonseWriter has been retired and tests have been added.

          There are no default values returned for fields not in the docs, I'm arguing that this is incorrect behavior and any code that depends on it needs to be re-written. We can discuss that of course....

          The test case I added ran afoul of LUCENE-7548. When that's committed the test case should be updated. See the comments in StreamingTest.checkSort.

          The /export handler seems to sort missing fields first/last as it should, it's just that using the /select handler to get the proper ordering seemed like a good idea rather than hard-coding the results as in the current patch. This test case should continue to run fine even after LUCENE-7548 is committed, it'll just be inelegant.

          Still to do: Run the entire test suite to see what, if anything, breaks. Will do that tonight.

          Show
          erickerickson Erick Erickson added a comment - Latest patch implement as we've discussed. The code changes are absolutely minimal but are made in ExportWriter since SortingResonseWriter has been retired and tests have been added. There are no default values returned for fields not in the docs, I'm arguing that this is incorrect behavior and any code that depends on it needs to be re-written. We can discuss that of course.... The test case I added ran afoul of LUCENE-7548 . When that's committed the test case should be updated. See the comments in StreamingTest.checkSort. The /export handler seems to sort missing fields first/last as it should, it's just that using the /select handler to get the proper ordering seemed like a good idea rather than hard-coding the results as in the current patch. This test case should continue to run fine even after LUCENE-7548 is committed, it'll just be inelegant. Still to do: Run the entire test suite to see what, if anything, breaks. Will do that tonight.
          Hide
          erickerickson Erick Erickson added a comment -

          Perhaps the final patch, pending the resolution of LUCENE-7548. Actually, it can be committed regardless. The LUCENE Jira shouldn't cause this test to fail.

          There was one tiny test failure where StreamExpressionTest was explicitly expecting zero to return for an empty field, but I think that was just verifying current behavior. I fixed that and all tests pass.

          Dennis Gove Joel Bernstein any comments? If there are no objections I'll commit this in a few days.

          Show
          erickerickson Erick Erickson added a comment - Perhaps the final patch, pending the resolution of LUCENE-7548 . Actually, it can be committed regardless. The LUCENE Jira shouldn't cause this test to fail. There was one tiny test failure where StreamExpressionTest was explicitly expecting zero to return for an empty field, but I think that was just verifying current behavior. I fixed that and all tests pass. Dennis Gove Joel Bernstein any comments? If there are no objections I'll commit this in a few days.
          Hide
          erickerickson Erick Erickson added a comment -

          Well, certainly not the final patch for 6x. Siiiggggh.

          Michael McCandlessAdrien GrandRobert Muir (and others). Just to check what I think I'm seeing...

          In trunk, ExportWriter has a bunch of clauses like:
          ` NumericDocValues vals = DocValues.getNumeric(reader, this.field);
          if (vals.advance(docId) == docId)

          { val = vals.longValue(); }

          else

          { val = 0; }

          ew.put(field, val);
          '
          but 6x just looks like:
          ` NumericDocValues vals = DocValues.getNumeric(reader, this.field);
          long val = vals.get(docId);
          ew.put(field, val);
          `

          and vals.get(docId) returns zero when a docValues field isn't in the document.

          So my question is: "Would you agree that returning nothing rather than zero for docValues fields that have no entry for a particular doc would require a lot of work in 6x?"

          I know there was a whole long discussion about this on the LUCENE Jira list some time ago but the resolution kind of escapes me and the patch is huge.

          Thanks.

          Show
          erickerickson Erick Erickson added a comment - Well, certainly not the final patch for 6x. Siiiggggh. Michael McCandless Adrien Grand Robert Muir (and others). Just to check what I think I'm seeing... In trunk, ExportWriter has a bunch of clauses like: ` NumericDocValues vals = DocValues.getNumeric(reader, this.field); if (vals.advance(docId) == docId) { val = vals.longValue(); } else { val = 0; } ew.put(field, val); ' but 6x just looks like: ` NumericDocValues vals = DocValues.getNumeric(reader, this.field); long val = vals.get(docId); ew.put(field, val); ` and vals.get(docId) returns zero when a docValues field isn't in the document. So my question is: "Would you agree that returning nothing rather than zero for docValues fields that have no entry for a particular doc would require a lot of work in 6x?" I know there was a whole long discussion about this on the LUCENE Jira list some time ago but the resolution kind of escapes me and the patch is huge. Thanks.
          Hide
          mikemccand Michael McCandless added a comment -

          Erick Erickson in 6.x you could use docsWithField to know (after seeing a 0 from vals.get) that there was no value for this document.

          Show
          mikemccand Michael McCandless added a comment - Erick Erickson in 6.x you could use docsWithField to know (after seeing a 0 from vals.get ) that there was no value for this document.
          Hide
          erickerickson Erick Erickson added a comment -

          Thanks a million, that fixes me right up!

          I looked briefly at the underlying code and from what I saw on a quick scan this shouldn't be an expensive call even in those situations where there are a large number of docs without values. I'll see if I can uncrank one of my perf tests.

          Thanks again!

          Show
          erickerickson Erick Erickson added a comment - Thanks a million, that fixes me right up! I looked briefly at the underlying code and from what I saw on a quick scan this shouldn't be an expensive call even in those situations where there are a large number of docs without values. I'll see if I can uncrank one of my perf tests. Thanks again!
          Hide
          erickerickson Erick Erickson added a comment -

          I did some quick timing tests and there's no performance penalty, and actually a gain. I have two shards and this is all local on my laptop. 4 runs returning 10M rows.

          Bringing back:

          two fields with values: 36 seconds for 10M rows
          twi fields returning defaults: roughly the same as the above.
          two fields without values: 32 seconds

          The fields without values don't return anything for the field, it's just left out of the doc. I suspect the difference is converting it to a string and/or transmitting down to the client and/or parsing more JSON. (even though it's all on my laptop).

          Show
          erickerickson Erick Erickson added a comment - I did some quick timing tests and there's no performance penalty, and actually a gain. I have two shards and this is all local on my laptop. 4 runs returning 10M rows. Bringing back: two fields with values: 36 seconds for 10M rows twi fields returning defaults: roughly the same as the above. two fields without values: 32 seconds The fields without values don't return anything for the field, it's just left out of the doc. I suspect the difference is converting it to a string and/or transmitting down to the client and/or parsing more JSON. (even though it's all on my laptop).
          Hide
          noble.paul Noble Paul added a comment -

          Erick, i hope i didn't screw up things badly while refactoring the response writer. Please let me know if i can contribute.

          Show
          noble.paul Noble Paul added a comment - Erick, i hope i didn't screw up things badly while refactoring the response writer. Please let me know if i can contribute.
          Hide
          erickerickson Erick Erickson added a comment -

          I think this is very close to ready, so putting this patch up as a checkpoint. Many thanks to Mike for his help, and Noble for volunteering to help out.

          It's late and I'm getting tired enough that I don't trust myself to look at code any more. So checkpointing this, I'll look at it again over the weekend if I have time.

          Assuming I don't see any problems, I'll commit this sometime next week, so speak up if you object.

          Joel Bernstein Dennis Gove Kevin Risden Speak up now or forever hold your peace!

          BTW, what's "the git way" when you can't merge a push to trunk? Just push to each branch?

          Show
          erickerickson Erick Erickson added a comment - I think this is very close to ready, so putting this patch up as a checkpoint. Many thanks to Mike for his help, and Noble for volunteering to help out. It's late and I'm getting tired enough that I don't trust myself to look at code any more. So checkpointing this, I'll look at it again over the weekend if I have time. Assuming I don't see any problems, I'll commit this sometime next week, so speak up if you object. Joel Bernstein Dennis Gove Kevin Risden Speak up now or forever hold your peace! BTW, what's "the git way" when you can't merge a push to trunk? Just push to each branch?
          Hide
          noble.paul Noble Paul added a comment -

          I commit it first to trunk and cherry-pick the changes to 6x

          Show
          noble.paul Noble Paul added a comment - I commit it first to trunk and cherry-pick the changes to 6x
          Hide
          erickerickson Erick Erickson added a comment -

          That's what I usually do too, but in this case the code might be incompatible. I guess my real question is whether there's any harm in the two-patch idea.

          I had a chance to review this code on my flight and unless there are objectsions, I'm going to commit this to both branches probably tomorrow or Monday.

          Show
          erickerickson Erick Erickson added a comment - That's what I usually do too, but in this case the code might be incompatible. I guess my real question is whether there's any harm in the two-patch idea. I had a chance to review this code on my flight and unless there are objectsions, I'm going to commit this to both branches probably tomorrow or Monday.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 4a31b29cb031a10d25de01e25d1d9e5b1a4a7787 in lucene-solr's branch refs/heads/master from Erick Erickson
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4a31b29 ]

          SOLR-9166: Export handler returns zero for numeric fields that are not in the original doc

          Show
          jira-bot ASF subversion and git services added a comment - Commit 4a31b29cb031a10d25de01e25d1d9e5b1a4a7787 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4a31b29 ] SOLR-9166 : Export handler returns zero for numeric fields that are not in the original doc
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 375dd323a729035e2c957ecb49a6b88135e3edfd in lucene-solr's branch refs/heads/branch_6x from Erick Erickson
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=375dd32 ]

          SOLR-9166: Export handler returns zero for numeric fields that are not in the original doc

          Show
          jira-bot ASF subversion and git services added a comment - Commit 375dd323a729035e2c957ecb49a6b88135e3edfd in lucene-solr's branch refs/heads/branch_6x from Erick Erickson [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=375dd32 ] SOLR-9166 : Export handler returns zero for numeric fields that are not in the original doc
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          This has broken precommit. Please fix.

          Show
          shalinmangar Shalin Shekhar Mangar added a comment - This has broken precommit. Please fix.
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-9166: Export handler returns zero for numeric fields that are not in the original doc. Fixed precommit

          Show
          jira-bot ASF subversion and git services added a comment - Commit c0b7edb5c858ce5f3e6308b9c32747c5e3729acc in lucene-solr's branch refs/heads/master from Erick Erickson [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c0b7edb ] SOLR-9166 : Export handler returns zero for numeric fields that are not in the original doc. Fixed precommit
          Hide
          erickerickson Erick Erickson added a comment -

          Sorry for the pre-commit foo.

          Show
          erickerickson Erick Erickson added a comment - Sorry for the pre-commit foo.
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-9166: fix precommit

          Show
          jira-bot ASF subversion and git services added a comment - Commit ca80ba6b80be619ebeea1f6b8f0864832ebbfec8 in lucene-solr's branch refs/heads/master from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ca80ba6 ] SOLR-9166 : fix precommit

            People

            • Assignee:
              erickerickson Erick Erickson
              Reporter:
              erickerickson Erick Erickson
            • Votes:
              3 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development