uniqueKey type

We used a custom fieldType that segments the values of a
field A into
tokens.  We then define uniqueKey as that field A.  It seems
when we update
a document by solr, documents that have different values
(one contains the
other as a substring)  gets collided into one so the result
is the new
document removed the old one.

Does uniqueKey field has to be string typed?  How does the
comparison of the
values work for updating documents?


thanks,

-Hui

On 6-Nov-07, at 2:31 PM, Yu-Hui Jin wrote:

> We used a custom fieldType that segments the values of
a field A into
> tokens.  We then define uniqueKey as that field A.  It
seems when  
> we update
> a document by solr, documents that have different
values (one  
> contains the
> other as a substring)  gets collided into one so the
result is the new
> document removed the old one.
>
> Does uniqueKey field has to be string typed?  How does
the  
> comparison of the
> values work for updating documents?

uniqueKey needn't be string type, but the tokenizer must
produce a  
single token only (and any documents that have the same
resulting  
token will be considered "the same").

If this is violated, the behaviour is undefined (but I
wouldn't be  
surprised if the first token was used).

-Mike

Got it. Thanks, Mike.  That explains.


regards,

-Hui


On 11/6/07, Mike Klaas <mike.klaasgmail.com> wrote:
>
> On 6-Nov-07, at 2:31 PM, Yu-Hui Jin wrote:
>
> > We used a custom fieldType that segments the
values of a field A into
> > tokens.  We then define uniqueKey as that field A.
 It seems when
> > we update
> > a document by solr, documents that have different
values (one
> > contains the
> > other as a substring)  gets collided into one so
the result is the new
> > document removed the old one.
> >
> > Does uniqueKey field has to be string typed?  How
does the
> > comparison of the
> > values work for updating documents?
>
> uniqueKey needn't be string type, but the tokenizer
must produce a
> single token only (and any documents that have the same
resulting
> token will be considered "the same").
>
> If this is violated, the behaviour is undefined (but I
wouldn't be
> surprised if the first token was used).
>
> -Mike
>
>


-- 
Regards,

-Hui