: We are using Solrj to query our solr server, and it works great. 
: However, it uses the binary format wt=javabin, and now when I'm trying 
: to get better debug output, I notice a problem with this. The thing is, 
: I want to include the explain data for each search result, by adding 
: "[explain]" as a field for the fl parameter. And when using [explain 
: style=nl] combined with wt=json, the explain output is proper and valid 
: json. However, when I use something other than wt=json, the explain 
: output is not proper json.

Forget about qt param and/or the responsewriter/response parser used by 
SolrJ for a minute.

When you use "fl=[explain style=nl]" what's happening is that *structured* 
named list containing hte explanation metadata is included in each 
document in the response -- as opposed to "style=text" in which a simple 
whitespace indented string representation of the score explanation is 
included.

Now lets think about the "wt" param -- that controls how *structured* data 
is written over the wirte -- so with "fl=[explain style=nl]" the 
structurred score explanation is written over the wire as json with 
wt=json, or xml with wt=xml, or in solr's custom binary protocol with 
wt=javabin.

As a SolrJ user, regardless of what "wt" value is used by SolrJ under the 
covers, SolrJ will use an appropriate response parser to recreate the 
structure of the data in your client application.  So what you get in your 
java application when you access that psuedo-field on each document is 
going to depend on the (effective) "style" value of that transformer -- 
not the "wt" used.

So for "style=text" your client code will find a java.lang.String 
containing the same simple string representation mentioned above (just 
like you see in your browser with wt=json or wt=xml).  

for "style=nl" you're going to get back and 
org.apache.solr.common.NamedList object (with the same structure as what 
you would see in your browser with wt=xml or wt=json) which you can 
traverse using the appropriate java methods to pull out the various keys & 
values that you want.  if you simply call toString() on this object you're 
going to get a basic dump of the data which might look like broken JSON, 
but is relaly just an attempt at returning some useful toString() info for 
debugging.

I suspect that "NamedList.toString()" output is what's confusing 
you...

: And, the reason I want to explain segment in proper json format, is that 
: I want to turn it into a JSONObject, in order to get proper indentation 
: for easier reading. Because the regular output doesn't have proper 
: indentation.

in your java code, you can walk the NamedList structure you get back 
recursively, and call the appropraite methods to get the list of key=>val 
pairs to add them to convert it to a JSONObject.  There is no server side 
option to write the explain data back as a "String contianing a JSON 
representation of the structured data" which will then be passed as a raw 
string all the way back to the client.



-Hoss
http://www.lucidworks.com/

Reply via email to