You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by "Ali, Saqib" <do...@gmail.com> on 2013/08/01 18:02:12 UTC
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! :)
Re: uniqueKey: string vs. long integer
Posted by Jack Krupansky <ja...@basetechnology.com>.
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 <do...@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.petersen@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:jack@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! :)
> >
> >
> >
> >
>
Re: uniqueKey: string vs. long integer
Posted by Erick Erickson <er...@gmail.com>.
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 <do...@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.petersen@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:jack@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! :)
> >
> >
> >
> >
>
Re: uniqueKey: string vs. long integer
Posted by "Ali, Saqib" <do...@gmail.com>.
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.petersen@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:jack@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! :)
>
>
>
>
RE: uniqueKey: string vs. long integer
Posted by "Petersen, Robert" <ro...@mail.rakuten.com>.
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:jack@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! :)
Re: uniqueKey: string vs. long integer
Posted by Jack Krupansky <ja...@basetechnology.com>.
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! :)