[
https://issues.apache.org/jira/browse/SOLR-6051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998378#comment-13998378
]
Yonik Seeley commented on SOLR-6051:
------------------------------------
bq. The reason I submitted a bug is that there was no official documentation
(that I could find)
A while ago, I added this to schema.xml at the start of the fields section,
where people would hopefully see it when they were adding their own fields:
{code}
<!-- 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. Names with both leading and
trailing underscores (e.g. _version_) are reserved.
-->
{code}
> Field names beginning with numbers give different and incorrect results
> depending on placement in URL query
> -----------------------------------------------------------------------------------------------------------
>
> Key: SOLR-6051
> URL: https://issues.apache.org/jira/browse/SOLR-6051
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.7.2
> Environment: CentOS 6+
> Reporter: Mark Ebbert
> Priority: Minor
> Labels: documentation, patch
>
> I've looked all over for specific field name requirements and can't find any
> official documentation. Is there official documentation on field names? If
> not, *please* provide some!
> We created several field names that begin with numbers, but SOLR doesn't seem
> to handle that well. Here are two "identical" URL queries that produce
> different output:
> {quote}
> http://<our_server>:8080/solr/query?q=chr:19%20AND%20pos:16666101&fl=chr,pos,ref,alt,1000G_freq,AFR_freq,ASN_freq
> {quote}
> and
> {quote}
> http://<our_server>:8080/solr/query?q=chr:19%20AND%20pos:16666101&fl=chr,pos,ref,alt,AFR_freq,ASN_freq,1000G_freq
> {quote}
> The only difference between the two queries is the location of '1000G_freq'
> (middle vs. end). The first query does not return the 1000G_freq value but
> the second does. Additionally, both return a value that does not exist
> ("1000":1000). Seems to be doing something funky with the 1000 in the field
> name. The "1000":1000 disappears if I remove '1000G_freq' from the query.
> Here are the outputs from both queries:
> h2. Query 1 Results
> {code:title=Query 1 Results|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"chr,pos,ref,alt,1000G_freq,AFR_freq,ASN_freq",
> "q":"chr:19 AND pos:16666101"}},
> "response":{"numFound":5,"start":0,"docs":[
> {
> "chr":"19",
> "pos":16666101,
> "ref":"G",
> "alt":"C",
> "1000":1000},
> {
> "chr":"19",
> "pos":16666101,
> "ref":"G",
> "alt":"C",
> "AFR_freq":0.05,
> "ASN_freq":0.55,
> "1000":1000},
> {
> "chr":"19",
> "pos":16666101,
> "ref":"G",
> "alt":"C",
> "AFR_freq":0.05,
> "ASN_freq":0.55,
> "1000":1000},
> {
> "chr":"19",
> "pos":16666101,
> "ref":"G",
> "alt":"C",
> "1000":1000},
> {
> "chr":"19",
> "pos":16666101,
> "ref":"G",
> "alt":"C",
> "1000":1000}]
> }}
> {code}
> h2. Query 2 Results
> {code:title=Query 2 Results|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
> "fl":"chr,pos,ref,alt,AFR_freq,ASN_freq,1000G_freq",
> "q":"chr:19 AND pos:16666101"}},
> "response":{"numFound":5,"start":0,"docs":[
> {
> "chr":"19",
> "pos":16666101,
> "ref":"G",
> "alt":"C",
> "1000":1000},
> {
> "chr":"19",
> "pos":16666101,
> "ref":"G",
> "alt":"C",
> "1000G_freq":0.43,
> "AFR_freq":0.05,
> "ASN_freq":0.55,
> "1000":1000},
> {
> "chr":"19",
> "pos":16666101,
> "ref":"G",
> "alt":"C",
> "1000G_freq":0.43,
> "AFR_freq":0.05,
> "ASN_freq":0.55,
> "1000":1000},
> {
> "chr":"19",
> "pos":16666101,
> "ref":"G",
> "alt":"C",
> "1000":1000},
> {
> "chr":"19",
> "pos":16666101,
> "ref":"G",
> "alt":"C",
> "1000":1000}]
> }}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
