[
https://issues.apache.org/jira/browse/SOLR-9150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300292#comment-15300292
]
Peter Horvath commented on SOLR-9150:
-------------------------------------
Here is our use-case: imagine a system, where Solr is used as a backing store
of a hosted service, where a number of external customers regularly load their
data (bringing their own field names like "foo" and "bar"), build some UIs with
the tools you provide them for 3rd party users. In such environment you do not
know the fields stored in Solr (except load time, when you can look at the
values), and do not want to expose the implementation details of Solr being
used for the backend. Since you want to hide the fact that fields "foo" and
"bar" are actually stored internally as e.g "foo_i" and "bar_s", you will have
to implement some mapping logic in the application, translating back and forth
between the user view ("foo" and "bar" fields) and the actual backend names
"foo_i" and "bar_s" -- this is something I would desperately like to avoid.
I am not familiar with the internal workings of Solr, so I might be wrong, but
I though achieving something would be relatively easy: in Lucene it is, where
you can always add a new field when a document is inserted.
I think the operation should simply fail, in case an attempt is made to index a
document field with a different data type. E.g. someone created "foo" by
indexing "foo_i", then indexing a document with "foo_s" should simply be
rejected by an exception.
Am I right assuming that Solr does not simply rely on the field naming to know
the type of a dynamic field?
This does not necessarily has to be implemented in the core engine: I would be
happy with any solution, that allowed me to create fields without having to
query the current schema of a collection and then issue massive number of
schema change requests. (Adjusting the non-dynamic schema is plausible, but
still difficult for us: a user might change his/her mind and load completely
different data structure: we would have to purge dangling fields after
that...). An optional hook, extension etc would be perfectly fine for us. Or if
you have any better idea, how to deal with such requirements, I am much obliged
to hear you inputs.
> 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
