I think I have found an issue with using the long integer for uniqueKey*— *Document routing using ! notation will not work with a long integer uniqueKey :(
Thanks Jack and Robi On Thu, Aug 1, 2013 at 10:05 AM, Petersen, Robert < robert.peter...@mail.rakuten.com> wrote: > 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! :) > > > >
