lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Updated) (JIRA)" <>
Subject [jira] [Updated] (SOLR-3226) SignatureUpdateProcessor ignores non-string field values from the signature generation
Date Mon, 02 Apr 2012 19:41:22 GMT


Hoss Man updated SOLR-3226:

    Affects Version/s: 1.4
        Fix Version/s: 3.6
             Assignee: Hoss Man

I wanna commit this into 3.6 ... but i'd like to get mark miller to sanity check th patch
first (the instanceof String seems so deliberate i'm not sure if i'm missing something - i've
pinged him on IRC to see if he can review ASAP)

Suggested special text for the upgrading section in CHANGES.txt...

A bug found and fixed in the SignatureUpdateProcessor that previously caused some 
documents to produce the same signature even when the configured fields contained 
distinct (non-String) values.  Users of SignatureUpdateProcessor are strongly advised 
that they should re-index as document signatures may have now changed. 
(see SOLR-3226 for details)
> SignatureUpdateProcessor ignores non-string field values from the signature generation
> --------------------------------------------------------------------------------------
>                 Key: SOLR-3226
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>          Components: update
>    Affects Versions: 1.4, 3.1, 3.2, 3.3, 3.4, 3.5, 4.0
>            Reporter: Spyros Kapnissis
>            Assignee: Hoss Man
>             Fix For: 3.6
>         Attachments: SOLR-3226.patch, SOLR-3226.patch
> When using for example XMLUpdateRequestProcessor, the signature is calculated correctly
since all field values are strings. But when one uses DataImportHandler or BinaryUpdateRequestHandler,
the signature generation will ignore any field values that are ints, longs, dates etc. 
> This might result in overwriting non-similar documents, as it happened in my case while
importing some db data through DIH.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message