[
https://issues.apache.org/jira/browse/SOLR-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191075#comment-15191075
]
Jack Krupansky edited comment on SOLR-8831 at 3/11/16 3:49 PM:
---------------------------------------------------------------
Can we come up with a nice clean term for "stored or docValues are enabled"?
I mean, the issue title here is misleading, as the description then indicates -
"if docValues are enabled." So, it should be "allow _version_ field to be
unstored if docValues are enabled."
Traditional database nomenclature is no help here since the concept of
non-stored data is meaningless in a true database.
Personally, I'd be happier if Solr hid a lot of the byzantine complexity of
Lucene, including this odd distinction between stored and docValues. I mean, to
me they are just two different implementations of the logical concept of
storing data for later retreival - how the data is stored rather than whether
it is stored.
I'll offer two suggested simple terms to be used at the Solr level even if
Lucene insists on remaining byzantine: "xstored" or "retrievable", both meaning
that the field attributes make it possible for Solr to retrieve data after
indexing, either because the field is stored or has docValues enabled. This is
not a proposal for a feature, but simply terminology to be used to talk about
fields which are... "either stored or have docValues enabled." (If I wanted a
feature, it might be to have a new attribute like
retrieval_storage="\{by_field|by_document|none}" or...
stored="\{yes|no|docValues|fieldValues}".)
I'm not proposing any feature here since that would be out of the scope of the
issue, but since this issue needs doc, I am just proposing new terminology for
that doc.
Again, to summarize more briefly, I am proposed that the terminology of
"retrievable" be used to refer to fields that are either stored or have
docValues enabled.
was (Author: jkrupan):
Can we come up with a nice clean term for "stored or docValues are enabled"?
I mean, the issue title here is misleading, as the description then indicates -
"if docValues are enabled." So, it should be "allow _version_ field to be
unstored if docValues are enabled."
Traditional database nomenclature is no help here since the concept of
non-stored data is meaningless in a true database.
Personally, I'd be happier if Solr hid a lot of the byzantine complexity of
Lucene, including this odd distinction between stored and docValues. I mean, to
me they are just two different implementations of the logical concept of
storing data for later retreival - how the data is stored rather than whether
it is stored.
I'll offer two suggested simple terms to be used at the Solr level even if
Lucene insists on remaining byzantine: "xstored" or "retrievable", both meaning
that the field attributes make it possible for Solr to retrieve data after
indexing, either because the field is stored or has docValues enabled. This is
not a proposal for a feature, but simply terminology to be used to talk about
fields which are... "either stored or have docValues enabled." (If I wanted a
feature, it might be to have a new attribute like
retrieval_storage="{by_field|by_document|none}" or...
stored="{yes|no|docValues|fieldValues}".)
I'm not proposing any feature here since that would be out of the scope of the
issue, but since this issue needs doc, I am just proposing new terminology for
that doc.
Again, to summarize more briefly, I am proposed that the terminology of
"retrievable" be used to refer to fields that are either stored or have
docValues enabled.
> allow _version_ field to be unstored
> ------------------------------------
>
> Key: SOLR-8831
> URL: https://issues.apache.org/jira/browse/SOLR-8831
> Project: Solr
> Issue Type: Improvement
> Reporter: Yonik Seeley
> Attachments: SOLR-8831.patch
>
>
> Right now, one is prohibited from having an unstored _version_ field, even if
> docValues are enabled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
