[
https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148921#comment-15148921
]
Gus Heck commented on SOLR-8110:
--------------------------------
Disallowing the '.' character in field names will be difficult for one project
I work on. They are indexing fields of subordinate objects from an outside
system using '.' to separate and distinguish the fields that have been
denormalized onto the parent. This decision dates back over 3 years since
before I started working with them, and much has been built on this. The field
names from the system being indexed already contain '_' Yes one could use
double '_''_' except that double underscores actually occurs in the source data
too, so it would be on to triple '___' ... which gets hard to tell apart from
'__' and of course multi-character separators are more work for parsing. I'd
like to suggest that at least one more non-alphanum character be allowed, (of
course '.' is my preference). Having only one non-alphanumeric character
available would be painful.
> Start enforcing field naming recomendations in next X.0 release?
> ----------------------------------------------------------------
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
>
> For a very long time now, Solr has made the following "recommendation"
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only
> and not start with a digit. This is not currently strictly enforced, but
> other field names will not have first class support from all components and
> back compatibility is not guaranteed. ...
> I'm opening this issue to track discussion about if/how we should start
> enforcing this as a rule instead (instead of just a "recommendation") in our
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with
> lists of field and produce strange errors when the huerstic fails (example:
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the
> recommended conventions and then only later encountering a situation where
> their field names are not supported by some feature and get frustrated
> because they have to change their schema, reindex, update index/query client
> expectations, etc...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
