Re: UpdateHandler-Bug or intended feature?

[Chris Hostetter <ho...@fucit.org>]

: Well, this does not seem to me like a bug but more like an exotic
: situation where two concepts collidate with eachother.
: The CSVRequestHandler is intended to sweep all the unneccessary stuff
: out of the input to avoid exceptions for unknown fields
: while my UpdateRequestProcessor needs such fields to work correctly.

Agreed, this is an interesting edge case ... i don't actaully see any 
reason why CSVRequestHandler needs the SchemaField for each field name -- 
all it ever seems to use it for is determining hte field name, so it would 
probably be easy to rip out.

i think even if CSVRequestHandler has some reason for wanting the 
SchemaField object, it should gracefully handle the case where it can't be 
found (there's a version of the method it calls that returns null instead 
of throwing an exception) and just passing the fieldname=val pairs into 
the SolrInputDocument for the UpdateProcessor to deal with -- if there 
really is a problem (and nothing ever removes/maps that field) the 
underlying "add" code will eventually fail with the same exception.

Please feel free to open a Jira issue for this -- it would help in 
particular if you could mention the gist of your usecase (why you include 
columns that don't map directly to fields and what your UpdateProcessor 
does with them) so people better understand the goal.

-Hoss

Re: UpdateHandler-Bug or intended feature?

[Em <ma...@yahoo.de>]

Hi Hoss,

actually I thought this would be neccessary for the SolrInputDocument to map
against a special FieldType, but this isn't true. The mapping comes
sometimes after the UpdateProcessor finished its work.
So yes, there is no reason to force the CSVRequestHandler to throw an
Exception if the field does not exist.

I will register at the Jira and open an issue for that today.

Regards


Chris Hostetter-3 wrote:
> 
> 
> : Well, this does not seem to me like a bug but more like an exotic
> : situation where two concepts collidate with eachother.
> : The CSVRequestHandler is intended to sweep all the unneccessary stuff
> : out of the input to avoid exceptions for unknown fields
> : while my UpdateRequestProcessor needs such fields to work correctly.
> 
> Agreed, this is an interesting edge case ... i don't actaully see any 
> reason why CSVRequestHandler needs the SchemaField for each field name -- 
> all it ever seems to use it for is determining hte field name, so it would 
> probably be easy to rip out.
> 
> i think even if CSVRequestHandler has some reason for wanting the 
> SchemaField object, it should gracefully handle the case where it can't be 
> found (there's a version of the method it calls that returns null instead 
> of throwing an exception) and just passing the fieldname=val pairs into 
> the SolrInputDocument for the UpdateProcessor to deal with -- if there 
> really is a problem (and nothing ever removes/maps that field) the 
> underlying "add" code will eventually fail with the same exception.
> 
> Please feel free to open a Jira issue for this -- it would help in 
> particular if you could mention the gist of your usecase (why you include 
> columns that don't map directly to fields and what your UpdateProcessor 
> does with them) so people better understand the goal.
> 
> -Hoss
> 
> 

-- 
View this message in context: http://lucene.472066.n3.nabble.com/UpdateHandler-Bug-or-intended-feature-tp2389382p2395656.html
Sent from the Solr - User mailing list archive at Nabble.com.