[jira] [Commented] (SOLR-8831) allow _version_ field to be unstored
[ https://issues.apache.org/jira/browse/SOLR-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191090#comment-15191090 ] Yonik Seeley commented on SOLR-8831: bq. they are just two different implementations of the logical concept of storing data for later retreival I agree - I've been occasionally using the term "row stored" and "column stored". While we won't be able to totally squash the terms "stored" or "docValues" (too much history), in certain contexts it will certainly be easier to use an all encompassing term like "retrievable". I'll update this patch to reflect that unless someone comes up with a better word for it. > 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
[jira] [Commented] (SOLR-8831) allow _version_ field to be unstored
[
https://issues.apache.org/jira/browse/SOLR-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191075#comment-15191075
]
Jack Krupansky commented on SOLR-8831:
--
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
[jira] [Commented] (SOLR-8831) allow _version_ field to be unstored
[ https://issues.apache.org/jira/browse/SOLR-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190825#comment-15190825 ] Ishan Chattopadhyaya commented on SOLR-8831: +1, this is much needed. I used to keep something like this in my patch for SOLR-5944 (https://github.com/chatman/lucene-solr/commit/627b9ac9b46796f20be78b04ebbdfa4299b96ab7#diff-040ec312b12294ee52a94eac00766ea7L77). > 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
[jira] [Commented] (SOLR-8831) allow _version_ field to be unstored
[ https://issues.apache.org/jira/browse/SOLR-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190821#comment-15190821 ] Varun Thacker commented on SOLR-8831: - Hi Yonik, Was this committed as part in SOLR-5670 ? > 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
[jira] [Commented] (SOLR-8831) allow _version_ field to be unstored
[ https://issues.apache.org/jira/browse/SOLR-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190516#comment-15190516 ] David Smiley commented on SOLR-8831: +1 > 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
