[
https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15170264#comment-15170264
]
Shawn Heisey commented on SOLR-8110:
------------------------------------
Right now, the first attempts at validation (SOLR-8642) have resulted in
SOLR-8725. I believe that the restrictions in SOLR-8642 are the only ones that
will be safe for advanced and possible future features (like infix expressions
and separators that have meaning to Solr) that Yonik mentioned.
I've stared at my keyboard for several minutes trying to see whether there are
any other good choices for a meaningful separator character other than the
period, and all of the possibilities are either used for something else, or
they're really arcane and likely to cause the kind of problems we're aiming to
prevent with this issue. For that reason, I think that periods should be
banned for right now, and then only allowed in a limited fashion as necessary
to support that future separator idea, if it ever becomes a reality.
For my purposes, I'm perfectly OK with breaking backward compatibility in 6.0
and enforcing SOLR-8642 across the board. I will need to change my own core
names (which currently use hyphens), but I'm OK with that. Recognizing the
pain this could cause, I can get behind an approach where violations cause a
warning in 6.0, and default to enforcement later.
Parsing code tends to be extremely complex and fragile in the best conditions.
When a character that has special meaning in some contexts is allowed in
identifiers, that code is even more fragile. I would rather be more
restrictive on this issue than risk parser bugs.
> 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]
