[
https://issues.apache.org/jira/browse/SOLR-9150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15297154#comment-15297154
]
Shawn Heisey edited comment on SOLR-9150 at 5/24/16 8:42 PM:
-------------------------------------------------------------
Let's imagine an index that does not have a field named "foo", but does have
"\*_i" and "\*_s" dynamicField entries.
An indexing request comes in with number in a field named "foo_i". With this
feature, this would put that data into a Lucene field named "foo" ... but at
that point, how is Solr supposed to know that a query on the "foo" field should
be treated as a number? The only way I can imagine this working without
problems is if this action results in a managed_schema update that *adds* the
field named "foo" to the schema with the same definition as "*_i".
As a further thought experiment, what exactly should happen if a subsequent
indexing request contains a field named "foo_s" that holds a non-numeric
string? If the first request containing foo_i results in foo being added to a
managed schema, then a subsequent request with foo_s would fail, because the
incoming data would not be compatible with an integer field.
was (Author: elyograg):
Let's imagine an index that does not have a field named "foo", but does have
"*_i" and "*_s" dynamicField entries.
An indexing request comes in with number in a field named "foo_i". With this
feature, this would put that data into a Lucene field named "foo" ... but at
that point, how is Solr supposed to know that a query on the "foo" field should
be treated as a number? The only way I can imagine this working without
problems is if this action results in a managed_schema update that *adds* the
field named "foo" to the schema with the same definition as "*_i".
As a further thought experiment, what exactly should happen if a subsequent
indexing request contains a field named "foo_s" that holds a non-numeric
string? If the first request containing foo_i results in foo being added to a
managed schema, then a subsequent request with foo_s would fail, because the
incoming data would not be compatible with an integer field.
> Add configuration option to strip type postfix from dynamic field name on
> document indexing
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-9150
> URL: https://issues.apache.org/jira/browse/SOLR-9150
> Project: Solr
> Issue Type: New Feature
> Components: Server
> Affects Versions: 6.0
> Reporter: Peter Horvath
>
> In some cases, incorporating field type indication to the name of a dynamic
> field is not desirable.
> It would be great if there was a configuration option (global, instance level
> or collection-level), which instructed Solr to create dynamic fields with the
> type postfix stripped.
> For example, suppose the schema contained a dynamic field with a name of
> "*_i". If the user attempts to index a document with a "cost_i" field, but no
> explicit "cost_i" field is defined in the schema, then a "cost" field
> (without "_i" postfix) would be created with the field type and analysis
> defined for "*_i". As a result queries could be executed against the dynamic
> field being referred to without the type indicator postfix: "cost:10"
> To retain backward compatibility, this feature should have to be enabled
> explicitly.
--
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
