[
https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15169830#comment-15169830
]
Jack Krupansky commented on SOLR-8110:
--------------------------------------
Dot is a tough case. I can see reserving it for future expansion, but I can
also see its utility in field names where its value is based on using it as a
pseudo-field delimiter, such as in cases where data may in fact have come from
an SQL ETL operation that actually did use the dot as a compound field name.
How about... saying that dot is pseudo-reserved for compound field name
references, and if the decomposed field name has a well-defined meaning in some
context, such as where there are contextual named structural entities, such as
table or collection names, then so be it, but if it has no clear meaning in a
context, then the full, dotted name will be treated as a raw field name? So, at
the level of the fl parameter a dotted name would get parsed as a compound name
and then treated as a simple field name.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
