[ https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159139#comment-15159139 ]
Shawn Heisey commented on SOLR-8110: ------------------------------------ bq. Since the concept of enforcement of naming conventions is new, I would suggest making it optional in 6.x, preferably out-out I'm in favor of more aggressive measures, particularly if we can get it complete before the 6.0 release ... but I won't argue against a less invasive plan. Here's a more complete idea for a less invasive approach: * In 6.0 (or 6.1, etc): ** Default behavior: Check all identifiers on startup or when an API call is made that adds a new identifier. If something fails validation, log/return a warning, but don't fail. ** Provide an enforcement option in solrconfig.xml to fail core startup and API calls when the restrictions are violated. I'm not sure whether that should be a single option for everything, or separate options for field names, core/collection names, etc. * In 7.0, or perhaps a later 6.x release, turn enforcement on by default. One question can be decided at that later date: Do we keep the option to turn off enforcement? I would prefer to not have that option once enforcement is default, but users will likely want it. > 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