: > FWIW: I was able to reproduce this using the example setup (i picked a : > doc id at random) �suspecting it was a bug in docFreq : : Probably just a null being passed in the text part of the term. : I bet Luke expects all field values to be strings, but some are binary.
I'm not sure i follow you ... i think you saying that naive assumptions in the LukeRequestHandler could result in it asking for the docFreq of a term that has a null string value because some field types are binary, except that... 1) 1.3 didn't have this problem 2) LukeRequestHandler.getDocumentFieldsInfo didn't change from 1.3 to 1.4 I tied to reproduce this in 1.4 using an index/configs created with 1.3, but i got a *different* NPE when loading this url... http://localhost:8983/solr/admin/luke?id=SP2514N SEVERE: java.lang.NullPointerException at org.apache.solr.util.NumberUtils.SortableStr2int(NumberUtils.java:127) at org.apache.solr.util.NumberUtils.SortableStr2float(NumberUtils.java:83) at org.apache.solr.util.NumberUtils.SortableStr2floatStr(NumberUtils.java:89) at org.apache.solr.schema.SortableFloatField.indexedToReadable(SortableFloatField.java:62) at org.apache.solr.schema.SortableFloatField.toExternal(SortableFloatField.java:53) at org.apache.solr.handler.admin.LukeRequestHandler.getDocumentFieldsInfo(LukeRequestHandler.java:245) ...all three of these stack traces seem to suggest that some imple of Fieldable.stringValue in 2.9 is returning null in cases where it returned *something* else in the 2.4-dev jar used by Solr 1.3. That seems like it could have other impacts besides LukeRequestHandler. -Hoss
