After some investigation of my own. I've found that indexes don't actually have to be lowercased. The issue is with how Sitecore sends the query to SOLR. Take the example query below:
?q=(_fullpath:(\/sitecore/content*) AND _template:(113102dfb569477791acfffc90244536))&rows=2147483647&fl=*,score&fq=_indexname:(myIndex_sitecore_master_index)
The index, in this case, is named myIndex_sitecore_master_index
. Sitecore is able to ping the index properly, but no results are returned. The issue is that Sitecore also pushes the FilterQuery (fq
) parameter with the query. The value for _indexname
passed is myIndex_sitecore_master_index
. At first glance, this doesn't appear to be a problem, however, after reviewing the stored documents, the _indexname
field is stored as the lowercase variant on each document:
(JSON response)
...
"__lock_s": "sitecoreuser",
"_version": "1",
"_template": "113102dfb569477791acfffc90244536",
"_indexname": "myindex_sitecore_master_index",
"_version_": 1582958236651225000,
"_indextimestamp": "2017-11-02T12:43:34.2Z"
...
Therefore this document does not satisfy the FilterQuery parameter and thus, no documents are returned. Effectively, the fq
parameter is combined with the earlier q
parameter, but the fq
piece is cached. Therefore, Sitecore (in my example) is looking for a document where:
- Path starts with
/sitecore/content
- Has a Template ID of
113102dfb569477791acfffc90244536
- Has an
_indexname
of myIndex_sitecore_master_index
<- this fails
I will submit this to Sitecore as a bug since if they passed the fq
parameter as the lowercase variant, this would not be an issue.
--- Edit ---
Confirmed Sitecore bug: 140821