[ 
https://issues.apache.org/jira/browse/SOLR-9166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15609484#comment-15609484
 ] 

Yonik Seeley commented on SOLR-9166:
------------------------------------

bq. 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.

bq.  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)



> Export handler returns zero for numeric fields that are not in the original 
> doc
> -------------------------------------------------------------------------------
>
>                 Key: SOLR-9166
>                 URL: https://issues.apache.org/jira/browse/SOLR-9166
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Erick Erickson
>            Assignee: Rohit
>         Attachments: SOLR-9166.patch
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to