[
https://issues.apache.org/jira/browse/SOLR-10833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-10833:
-----------------------------------------
Attachment: SOLR-10833.patch
Here is a new patch.
bq. something like...
I added those methods, but not to the interface as you suggested since they
were required by {{NumericFieldType}} (superclass to both, points and trie
fields).
bq. maybe make the the new "parse" methods take in the ErrorCode to use if they
trhow an exception?
All the cases where I change the parse method would actually be bad requests,
so I ended up not adding this. Some I didn't change and are still using the
un-wrapped parsing, like {{toNativeType(Object val)}}, the implementation of
that method tries to handle the NFE (equally for both Trie* and Point* fields)
to some extent. For creating new fields, I decided to keep the current
exception handling, done by {{DocumentBuilder}}.
Added some more tests, including QParsers where Points currently work. For some
QParsers Points maybe should work (raw, simple...), but I think they deserve
their own Jiras/discussion if they don't have one already. See
{code:java}
// Skipping: func, boost, raw, nested, frange, spatial*, join, surround,
switch, parent, child, collapsing,
// complexphrase, rerank, export, mlt, hash, graph, graphTerms, igain,
tlogit, sigificantTerms, payload*
// Maybe add: raw, join, parent, child, collapsing, graphTerms, igain,
sigificantTerms, simple
{code}
> Numeric FooPointField classes inconsistent with TrieFooFields on malformed
> input: throw NumberFormatException
> -------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-10833
> URL: https://issues.apache.org/jira/browse/SOLR-10833
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10833.patch, SOLR-10833.patch, SOLR-10833.patch,
> SOLR-10833.patch
>
>
> Trie based Numeic fields deal with bad input by wrapping
> NumberFormatExceptions in w/BAD_REQUEST SolrExceptions -- PointFields are
> just allowing the NumberFormatExceptions to be thrown as is, which means they
> propagate up and are eventually treated as a SERVER_ERROR when responding to
> clients.
> This is not only inconsistent from an end user perspective -- but also breaks
> how these errors are handled in SolrCloud when the requests have been
> forwarded/proxied.
> We should ensure that the FooPointField classes behave consistently with the
> TrieFooField classes on bad input (both when adding a document, or query
> creating a field query)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
