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

Erick Erickson commented on SOLR-9187:
--------------------------------------

[~romseygeek]: I'm about to commit this patch and running afoul of  SOLR-9176. 

The root is this line in SimpleFacets:
       /* Always use filters for booleans... we know the number of values is 
very small. */
       if (type instanceof BoolField) 

For a DV-only field it defaults to FacetMethod.ENUM which doesn't work.

I can get around it by something like this (still testing):
       if (type instanceof BoolField && (field.indexed() == true || 
field.hasDocValues() == false)) 

I'm always suspicious of increasingly complex tests like this. So my question 
is whether this optimization should be removed? Or just keep it with additional 
clauses? I'm coming down on the side of leaving it in, but wanted to get your 
thoughts (or anyone else who wants to chime in of course).

The other thing I wanted to check is whether it's better to compute facets from 
the indexed values or the DV fields when _both_ are set. My supposition is that 
the ENUM method on the indexed fields is the better choice since it'll then 
cache the results.



> Support dates and booleans in /export handler, support boolean DocValues 
> fields
> -------------------------------------------------------------------------------
>
>                 Key: SOLR-9187
>                 URL: https://issues.apache.org/jira/browse/SOLR-9187
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>         Attachments: SOLR-9187.patch, SOLR-9187.patch
>
>
> Since these can be DV fields it seems like it should. The first-level problem 
> is that SortingResponseWriter doesn't check for date types as a legal export 
> value. Whether there are repercussions elsewhere I don't know yet.



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