IMO, simply having a standard at least gives us a standard and a reason to
fix the edge cases. As it stands now, there's no basis to even say
something should be fixed. So periods are fine as far as I'm concerned.
On Feb 17, 2016 10:49, "Shawn Heisey (JIRA)" <j...@apache.org> wrote:

>
>     [
> https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15149605#comment-15149605
> ]
>
> Shawn Heisey commented on SOLR-8110:
> ------------------------------------
>
> With the caveat that I haven't actually tried it and haven't looked at
> code, I can't immediately think of any reason periods would cause any
> problems, at least not with the top three query parsers -- lucene, dismax,
> and edismax.
>
> > 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
>
>

Reply via email to