lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Krupansky (JIRA)" <>
Subject [jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?
Date Wed, 17 Feb 2016 20:38:18 GMT


Jack Krupansky commented on SOLR-8110:

It would be nice to say that a "Solr identifier" had the same rules as a Java identifier,
but Java allows dollar signs and excludes keywords and reserved terms like if, for, true,
false, null. Hmmm... I don't know if many people would complain is Solr didn't allow those
keywords as field names.

The main three exceptions to the current soft-rule that I have run across are:

1. Dot for compound names.
2. Hyphen feels a little more natural than underscore unless you're truly thinking about Java
code and imagining that you could write a minus sign for a subtraction operation.
3. An ISO date/time value for dynamic fields which want to be time stamped. An optional text
keyword prefix and hyphen are common for these timestamped columns as well.
4. Spaces, but I think sensible people can accept those as not permitted in names.

The main difficulty I am aware of in Solr is parsing of function queries, including (or especially)
in the field list of the fl parameter.

> Start enforcing field naming recomendations in next X.0 release?
> ----------------------------------------------------------------
>                 Key: SOLR-8110
>                 URL:
>             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)
> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message