[
https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159191#comment-15159191
]
Anshum Gupta edited comment on SOLR-8110 at 2/23/16 5:06 PM:
-------------------------------------------------------------
I personally would prefer the more invasive approach here.
bq. Provide an enforcement option in solrconfig.xml to fail core startup
Though that sounds reasonable, I strongly feel it'll come back to bite the
users when they are unable to use certain features they want to use and the
only way out at times would be re-indexing plus changing the client code.
bq. I would prefer to not have that option once enforcement is default, but
users will likely want it.
If we give it to them, they would want it. I really think that enforcing
restrictions on identifiers isn't a game changer for the end users. Specially
considering the fact that we're supporting most use cases in the set of allow
chars.
In all here are the questions it boils down to:
# What is the set of allowed chars, and the rules ? - I think we are fine with
alphanumeric, dash, dot, and periods for this.
# Enforcement details
* Is this mandatory
* Do we enable it by default. If not, how can users enable it. If yes, how do
they disable it.
I suggest we use luceneMatchVersion for this. It might restrict users from
using more new features just to disable naming restrictions but that's a call
we'd have to make.
[~hossman] suggestions?
was (Author: anshumg):
I personally would prefer the more invasive approach here.
bq. Provide an enforcement option in solrconfig.xml to fail core startup
Though that sounds reasonable, I strongly feel it'll come back to bite the
users when they are unable to use certain features they want to use and the
only way out at times would be re-indexing plus changing the client code.
bq. I would prefer to not have that option once enforcement is default, but
users will likely want it.
If we give it to them, they would want it. I really think that enforcing
restrictions on identifiers isn't a game changer for the end users. Specially
considering the fact that we're supporting most use cases in the set of allow
chars.
In all here are the questions it boils down to:
# What is the set of allowed chars, and the rules ? - I think we are fine with
alphanumeric, dash, dot, and periods for this.
# Enforcement details
* Is this mandatory
* Do we enable it by default. If not, how can users enable it. If yes, how do
they disable it.
I suggest we use luceneMatchVersion for this. It might restrict users from
using more new features just to disable naming restrictions but that's a call
we'd have to make.
> 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
