[
https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15151121#comment-15151121
]
Jack Krupansky commented on SOLR-8110:
--------------------------------------
It would be nice to say that a "Solr identifier" had the same rules as a Java
identifier, but Java allows dollar signs and excludes keywords and reserved
terms like if, for, true, false, null. Hmmm... I don't know if many people
would complain is Solr didn't allow those keywords as field names.
The main three exceptions to the current soft-rule that I have run across are:
1. Dot for compound names.
2. Hyphen feels a little more natural than underscore unless you're truly
thinking about Java code and imagining that you could write a minus sign for a
subtraction operation.
3. An ISO date/time value for dynamic fields which want to be time stamped. An
optional text keyword prefix and hyphen are common for these timestamped
columns as well.
4. Spaces, but I think sensible people can accept those as not permitted in
names.
The main difficulty I am aware of in Solr is parsing of function queries,
including (or especially) in the field list of the fl parameter.
> 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]
