Hmm... haven't run into the case where null was returned in a multi-valued
scenario yet... I probably just haven't tested that case. I likely need to
add a null check there - thanks for pointing it out.
-Trey
On Fri, Nov 29, 2013 at 6:10 AM, Müller, Stephan <
muel...@ponton-consulting.de> wrote
Hello Trey, thank you for this example.
We've solved it by omitting the multivalued field and passing the distinct
string fields instead, still I go with proposing a patch, so the language
processor is able to concatenate multivalues by default. I think it's a
reasonable feature (and can't reme
Yeah, the documentation is definitely wrong - it definitely doesn't
concatenate the values in a multivalued field, it only uses the first one
like you mentioned.
If you want to detect the language of each of the values in the
multi-valued field (as opposed to specifying multiple separate string
va
-user@lucene.apache.org
Betreff: RE: LanguageIdentifierUpdateProcessor uses only firstValue() on
multivalued fields
> I suspect that it is an oversight for a use case that was not considered.
> I mean, it should probably either ignore or convert non text/string
> values.
Ok, I'll see tha
> I suspect that it is an oversight for a use case that was not considered.
> I mean, it should probably either ignore or convert non text/string
> values.
Ok, I'll see that I provide a patch against trunk. It actually
ignores non string values, but is unable to check the remaining values
of a mul
I suspect that it is an oversight for a use case that was not considered. I
mean, it should probably either ignore or convert non text/string values.
Hmmm... are you using JSON input? I mean, how are the types being set? Solr
XML doesn't have a way to set the value types.
You could workaround
