I think that form of routing is optional, so it's not required for Cloud per
se.
Still, I think we're back to what I suggested, that this is another Solr
feature that CAN be used, but doesn't necessarily work everywhere in Solr
(like field names containing white space or special characters.)
I think what is really needed is another one of your magic matrices, like
the one for field attributes and Solr features. Maybe just add a column for
non-string keys.
Hmmm... is that table in the new ref guide? If not, it should be moved from
the wiki. (Not sure how it would fit in the PDF format.
-- Jack Krupansky
-----Original Message-----
From: Erick Erickson
Sent: Friday, August 02, 2013 7:23 AM
To: solr-user@lucene.apache.org
Subject: Re: uniqueKey: string vs. long integer
And last I knew (admittedly a long time ago) Query Elevation Component
would fail with a non-string type. So in Robert's case things would run
along fine forever until using QEV... Which, to be fair, may be never <G>..
This may have changed, but is an example of how the <uniqueKey> not
being a string type can pop up and bite you.
But the routing bit is critical for SolrCloud.
Best
Erick
On Thu, Aug 1, 2013 at 1:10 PM, Ali, Saqib <docbook....@gmail.com> wrote:
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! :)
>
>
>
>
