Hi guys, We have used an integer as our unique key since solr 1.3 with no problems at all. We never thought of using anything else because our solr unique key is based upon our product sku data base field which is defined as an integer also. We're on solr 3.6.1 currently.
Thanks Robi -----Original Message----- From: Jack Krupansky [mailto:j...@basetechnology.com] Sent: Thursday, August 01, 2013 9:27 AM To: solr-user@lucene.apache.org Subject: Re: uniqueKey: string vs. long integer Although I cringe at the thought of anybody using anything other than a string for the unique key for a document, I can't point to any part of Solr that will absolutely fail. I wouldn't be surprised if there weren't a few nooks and crannies in Solr that might depend on the type of the ID, or at least depend on it being able to converted to and from string. I'm not sure if SolrCloud has any dependence on the document ID field type. Could you inquire as to why this third party chose to go with a non-string document key? Just curious if they perceived some advantage. I mean, is the key used in numeric calculations? Can it be negative? Is it ever sorted? But as a Solr best practice, I'd advise against it. -- Jack Krupansky -----Original Message----- From: Ali, Saqib Sent: Thursday, August 01, 2013 12:02 PM To: solr-user@lucene.apache.org Subject: uniqueKey: string vs. long integer We have an application that was developed by a third party. It uses uniqueKey that is a long integer instead of a string. Will there be any repercussions of using a long integer instead of string for the uniqueKey? Thanks! :)
