[
https://issues.apache.org/jira/browse/SOLR-14454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108602#comment-17108602
]
David Smiley commented on SOLR-14454:
-------------------------------------
Can you try to add this functionality to TextField or to a new subclass of
TextField? The objective is to ensure we can use keyword search if we want to.
If the user doesn't need keyword search, they can simply set indexed=false as
they can do so today. The cons for a subclass is that it's yet another field
type when TextField is already a fine name. However, the semantic meaning of
"docValues" to Solr users is
sort-able/facet-able/group-able/function-query(ValueSource) relevancy... and
here this is a different meaning. Still; this'd be a minor exception, and a
subclass might not avoid that issue. Also when switching it'd be nice to not
have to change the field type merely because you want DocValues too (for the
use case here).
> support for UTF-8 (string) types with DocValuesType.BINARY
> ----------------------------------------------------------
>
> Key: SOLR-14454
> URL: https://issues.apache.org/jira/browse/SOLR-14454
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
> Affects Versions: master (9.0)
> Reporter: Michael Gibney
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The goal is to add support for string fields with arbitrarily large values in
> the {{/export}} handler and streaming expressions.
> {{StrField}} values are currently limited to 32766 bytes for the case where
> {{indexed=true}} or {{docValues=true}}. Exceeding this value triggers an
> "immense field" warning, and causes indexing to fail for the associated input
> doc.
> Configuring a {{StrField}} field as "{{indexed=false docValues=false}}"
> removes this size limitation, so it is already possible to have large
> _stored_ {{StrField}} values. But the "{{docValues=true}}" prerequisite for
> the {{/export}} handler (and consequently for streaming expressions) limits
> the size of field that can be used in conjunction with these features.
> Adding support for UTF-8/string field types with {{DocValuesType.BINARY}}
> would address this limitation and allow considerable flexibility in the
> implementation of custom field types. N.b.: this would address field value
> retrieval use cases only (e.g., {{/export}} and {{useDocValuesAsStored}});
> neither sorting nor faceting would be supported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
