[
https://issues.apache.org/jira/browse/SOLR-8344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15034324#comment-15034324
]
Erick Erickson commented on SOLR-8344:
--------------------------------------
[~ichattopadhyaya] I think it'd solve the use-case. and I'm +1 on adding
stored().
I'm also concerned with the upgrade case though. If someone takes their 5x
schema and app (and I'm assuming all this is 6.0 at the earliest) and does
nothing to their schema or app, I'd like them to see no change. If we require
them to use stored() to pull the stored value explicitly, the app needs to
change or the users will be surprised.
Which is why I kinda like the stored=docvalues option. It would mean that they
get the same behavior they see now if they do nothing, but the option of doing
things the new way without re-indexing.
Hmmm, I like _also_ adding the stored() option. That would allow someone to
take an existing schema/index/app, add stored=docvalues option (for fields that
are _already_ DV fields) and _still_ get the raw stored value if they want.
Hmmmmm2. the more I think about it, the more I think that it's probably better
to have something like a new option. Rather than stored=docvalues, something
like defaultStoredReturn=docvalues|stored. That would allow an _existing_ index
with a DV field to have the maximum flexibility. Plus it would allow a single
field definition to serve all the use cases. My original idea of
stored=docvalues wouldn't put anything in the fdt files when indexing, so a
stored() operation wouldn't work on a new index.
Hmmmmm3. Maybe I'm worrying too much about flexibility. We already have enough
trouble explaining the nuances of stored/indexed/docValues. Adding
defaultStoredReturn to the mix makes it _really_ ugly. Just using
stored=docvalues allows people to make a decision, and the back-compat story is
simple. "To take advantage of these efficiencies, you may have to reindex if
you care about the edge case of floats/doubles/ints/longs (and maybe dates)".
> Decide default when requested fields are both column and row stored.
> --------------------------------------------------------------------
>
> Key: SOLR-8344
> URL: https://issues.apache.org/jira/browse/SOLR-8344
> Project: Solr
> Issue Type: New Feature
> Reporter: Ishan Chattopadhyaya
>
> This issue was discussed in the comments at SOLR-8220. Splitting it out to a
> separate issue so that we can have a focused discussion on whether/how to do
> this.
> If a given set of requested fields are all stored and have docValues (column
> stored), we can retrieve the values from either place. What should the
> default be?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
