[
https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159441#comment-15159441
]
Shawn Heisey commented on SOLR-8110:
------------------------------------
The core characters we need are letters, numbers, and the underscore. Consensus
seems to be that we allow dots (periods). If dashes (hyphens) are allowed,
then they cannot be the first character, or that will cause confusion with
negated query clauses and possibly cause other problems.
Underscores must be allowed as the first character, so \_version\_ and other
special fields used internally will work. My personal opinion is that the
first character must be a letter or an underscore, so we don't have to worry
about fixing bugs related to identifiers that start with a number.
One unanswered question is whether to only allow ASCII, or if "letters and
numbers" should include all matching characters in Unicode. My bias, which I
admit is completely provincial and might be far too restrictive, is ASCII.
A dedicated config option might be better than luceneMatchVersion, but I'm OK
either way. There are users who must use an old version number even with newer
versions of Solr. Changes to WordDelimiterFilter in 4.8 have a number of
people using 4.7 in luceneMatchVersion.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
