[
https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14938973#comment-14938973
]
Hoss Man commented on SOLR-8110:
--------------------------------
As far as the "how" to implement this, i think it would be pretty straight
forward...
* update the schema parsing and schema API code to enforce the naming
convention on "new" SchemaField instances
** use the same rules on prefix based dynamicFields
* update DocumentBuilder to enforce these rules when iterating over the
SolrInputFields to build up the underlying "Document" object passed to the
IndexWriter
** this will help catch any problematic fields that might satisfy a suffice
based dynamicField
* make all of this logic conditional on either the schema "version" or the
"luceneMatchVersion" and backport to the stable branch as well so it's optional
prior to the next X.0 release
** i'd lean towards making it depend on luceneMatchVersion is the better course
of action since that concept is designed around the idea that support for
"older" values is automatically dropped in future versions, where as the
"schema version" attribute has (so far) only ever been used to change the
default behavior of various schema features - enforce anything.
> 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
