[
https://issues.apache.org/jira/browse/SOLR-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182977#comment-13182977
]
Erick Erickson edited comment on SOLR-2987 at 1/10/12 1:24 AM:
---------------------------------------------------------------
Nice catch!
The only way I can generate this error is if the *keyfield* is a numeric type.
Otherwise, with string types, it works just fine because when the line like
"=76.0" is parsed, no attempt is made to convert the incoming key to anything.
And since there are no terms in the index that match the empty string, this
just gets collected as an error and logged. So your patch looks fine.
I don't see a good way to test this though, at least not in a positive sense. I
can include bogus entries in TestFunctionQuery for a start. I can add a test
for an *numeric* type keyfield modeled on testExternalFileFieldStringKeys, call
it testExternalFileFieldNumericKeys, leave off the key and see if it succeeds.
But on a quick glance, I don't see a good way to verify that the errors are
appropriately logged. Anyone want to weigh in on whether it's worth the effort?
was (Author: erickerickson):
Nice catch!
The only way I can generate this error is if the *keyfield* is a numeric type.
Otherwise, with string types, it works just fine because when the line like
"=76.0" is parsed, no attempt is made to convert the incoming value to
anything. And since there are no terms in the index that match the empty
string, this just gets collected as an error and logged. So your patch looks
fine.
I don't see a good way to test this though, at least not in a positive sense. I
can include bogus entries in TestFunctionQuery for a start. I can add a test
for an integer type keyfield modeled on testExternalFileFieldStringKeys, call
it testExternalFileFieldNumericKeys, leave off the key and see if it succeeds.
But on a quick glance, I don't see a good way to verify that the errors are
appropriately logged. Anyone want to weigh in on whether it's worth the effort?
> ExternalFileField With Invalid TrieField Key
> --------------------------------------------
>
> Key: SOLR-2987
> URL: https://issues.apache.org/jira/browse/SOLR-2987
> Project: Solr
> Issue Type: Bug
> Components: search
> Affects Versions: 3.5, 3.6, 4.0
> Reporter: Michael Garski
> Priority: Minor
> Attachments: eff_key_error.patch
>
>
> The current error handling in reading an external file field only catches an
> error when parsing the float value on a line, which then skips that line. If
> the key field is a trie field, such as a TrieIntField, and the key value in
> the file cannot be parsed to an int, loading of the entire file fails.
> Shouldn't the call to get the indexed value of the key should be in the same
> try/catch as the float parsing for the line?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
