: Processing chain (to avoid NFE): via XPath loaded into a field of type 
: text with a trim and length filter, then via copyField directive into 
: the tfloat type field

The root of the problem you are seeing is that copyField directives are 
applied to the *raw* field values -- the analyzer used on your "source" 
field won't have any effect on the values given to your "dest" field.

My suggestion would be to modify the XPath expression you are using to 
pull data out of your original XML files and ignore  "<estimated_hours/>"

Alternatively: there are some new UpdateProcessors available in 4.0 that 
let you easily prune field values based on various criteria (update 
porcessors happen well before copyField)...

http://lucene.apache.org/solr/api-4_0_0-ALPHA/org/apache/solr/update/processor/RemoveBlankFieldUpdateProcessorFactory.html


: Problem:
: Well, yet another NFE. But this time reported on the text field 
"s_estimated_hours":

I believe this is intentional, but i can understand how it might be 
confusing.

I think the point here is that since the field submitted by the client was 
named "s_estimated_hours" that's the field used in the error reported back 
to the client when something goes wrong with the copyField -- if the error 
message refered to "estimated_hours" the client may not have any idea 
why/where that field came from.

But i can certainly understand the confusion, i've opened SOLR-3657 to try 
and improve on this.  Ideally the error message should make it clear that 
the "value" from "source" field was copied to "dest" field which then 
encountered "error"

: 
: WARNUNG: Error creating document : SolrInputDocument[{id=id(1.0)={2930}, 
s_estimated_hours=s_estimated_hours(1.0)={}}]
: org.apache.solr.common.SolrException: ERROR: [doc=2930] Error adding field 
's_estimated_hours'=''
:       at 
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:333)
        ...
: Caused by: java.lang.NumberFormatException: empty String
:       at 
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:992)
:       at java.lang.Float.parseFloat(Float.java:422)
:       at org.apache.solr.schema.TrieField.createField(TrieField.java:410)
:       at org.apache.solr.schema.FieldType.createFields(FieldType.java:289)
:       at org.apache.solr.schema.SchemaField.createFields(SchemaField.java:107)
:       at 
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:312)
:       ... 11 more


-Hoss

Reply via email to