[
https://issues.apache.org/jira/browse/SOLR-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011884#comment-15011884
]
Yonik Seeley commented on SOLR-8220:
------------------------------------
bq. Added a ~ glob, similar to *. fl= here means: return all conventional
stored fields and all non stored docvalues.
Purely from an interface perspective (I haven't looked at the code), it feels
like this should be transparent.
It would be nice to be able to transition from an indexed+stored field to an
indexed+docValues field and not have any of the clients know/care.
{code}
fl=myfield // returns from either stored or docValues
fl=*_i // returns all stored or docValues fields ending in _i
fl=* // returns all stored fields and all docValues fields that are
not stored
{code}
If there is a need to distinguish between docValues as an alternative to a
stored field, and docValues as an implementation detail that you don't want to
return to the user (say you transitioned from an indexed-only field to an
indexed+docValues field or docValues-only field), then we could introduce a
field flag for the schema.
Something like includeInStored=true/false or asStored=true/false
> Read field from docValues for non stored fields
> -----------------------------------------------
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
> Issue Type: Improvement
> Reporter: Keith Laban
> Attachments: SOLR-8220-ishan.patch, SOLR-8220-ishan.patch,
> SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which
> requires redundant data to be stored on disk. Since reading from docValues is
> both efficient and a common practice (facets, analytics, streaming, etc),
> reading values from docValues when a stored version of the field does not
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as
> they would always be returned sorted in the docValues approach. I believe
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think
> it should live closer to where stored fields are loaded in the
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues,
> facets, analytics, streaming, etc, all seem to be doing their own ways,
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
> -- return field from docValue if the field is not stored and in docValues,
> if the field is stored return it from stored fields
> - fl="*"
> -- return only stored fields
> - fl="+"
> -- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first
> pass. 2b - is current behavior
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
