A search for "id" is much too broad. I looked at 3 of the SolrCloud classes you
mention and none of those "id"'s have anything to do with the unique field in
the schema. I have not looked at the hash based router, but if you find a real
issue then please file a JIRA issue.
- Mark
On Feb 12, 2013, at 10:00 PM, Shawn Heisey <s...@elyograg.org> wrote:
> On 2/12/2013 7:54 PM, Shawn Heisey wrote:
>> On 2/11/2013 7:47 PM, Mark Miller wrote:
>>> Doesn't sound right to me. I'd guess you heard wrong.
>>
>> I did a search for "id" with the quotes throughout the branch_4x source
>> code. After excluding test code, test files, and other things that
>> looked like they have good reason to be hardcoded, I was left with the
>> following:
>>
>> This class looks like a definite problem.
>> org.apache.solr.common.cloud.HashBasedRouter
>> Object idObj = sdoc.getFieldValue("id"); // blech
>>
>> This class uses "id" in a way that looks bad to me, but it's just for
>> logging:
>> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer
>>
>> I can't tell if use of "id" in these classes is problematic.
>> org.apache.solr.handler.admin.LukeRequestHandler
>> org.apache.solr.handler.admin.QueryElevationComponent
>> org.apache.solr.handler.component.RealTimeGetComponent
>> org.apache.solr.handler.loader.JsonLoader
>> org.apache.solr.handler.loader.XMLLoader
>> org.apache.solr.spelling.SpellCheckCollator
>>
>> These classes use "id" in a way that does not look problematic to me,
>> but should be reviewed.
>> org.apache.solr.cloud.ElectionContext
>> org.apache.solr.cloud.Overseer
>> org.apache.solr.cloud.OverseerCollectionProcessor
>> org.apache.solr.core.JmxMonitoredMap
>> org.apache.solr.handler.admin.ThreadDumpHandler
>
> Somehow I missed this one where I don't know if it's a problem:
>
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer
>
> Thanks,
> Shawn
>
