[
https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15170746#comment-15170746
]
Jan Høydahl commented on SOLR-8110:
-----------------------------------
I buy Yonik's arguments for reserving both dot and dash for future cool stuff.
When I argued for allowing these earlier it was as a compromise between chaos
(today) and pain (every Solr application needing a rewrite).
Perhaps we could define three modes for users to choose between, with pros/cons
documented:
"safe" - {{\[a-zA-Z0-9_\]}} only, guaranteed future proof, full SQL, script
support
"moderate" - safe + dash, dot, dollar and perhaps national unicode letters
"legacy" - no restrictions - only for easy back compat - will go away in 7.0
In 6.0, "moderate" would be the default, use of non-safe chars will be logged,
and users can revert to "legacy" if they wish, but will be aware of what
functionality they then sacrifice. In 7.0, "safe" could be made the default,
and allow people to revert to "moderate" but take away "legacy". This will
allow certain features to "bail out" with exception if in a mode that is known
to cause problems.
> 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
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> 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]
