[ 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