Apparently this was a side effect of the custom sharding feature. There is a fix planned, but I don't know more about it than that.
Michael Della Bitta ------------------------------------------------ Appinions 18 East 41st Street, 2nd Floor New York, NY 10017-6271 www.appinions.com Where Influence Isn’t a Game On Mon, Feb 11, 2013 at 7:15 PM, Shawn Heisey <s...@elyograg.org> wrote: > I have heard that SolrCloud may require the presence of a uniqeKey field > specifically named 'id' for sharding. > > Is this true? Is it still true as of Solr 4.2-SNAPSHOT? If not, what svn > commit fixed it? If so, should I file a jira? I am not actually using > SolrCloud for one index, but my worry is that once a precedent for putting > specific names in the code is set, it may bleed over into other features. > Also, I have another set of servers for a different purpose that ARE using > SolrCloud. Currently that system uses numShards=1, but one day we might > want to do a distributed search there. > > Both my systems have a uniqueKey field other than 'id' and it would be quite > a task to change it. The 'id' field doesn't exist at all in either system. > Here's relevant info for one of the systems: > > <field name="tag_id" type="lowercase" indexed="true" stored="true" > omitTermFreqAndPositions="true"/> > > <!-- lowercases the entire field value --> > <fieldType name="lowercase" class="solr.TextField" > sortMissingLast="true" positionIncrementGap="0" omitNorms="true"> > <analyzer> > <tokenizer class="solr.KeywordTokenizerFactory"/> > <filter class="solr.ICUFoldingFilterFactory"/> > <filter class="solr.TrimFilterFactory"/> > </analyzer> > </fieldType> > > <uniqueKey>tag_id</uniqueKey> > > Thanks, > Shawn
