Note that we now have to add a default param to the requestHandler:
<requestHandler name="/search"
class="org.apache.solr.handler.component.SearchHandler">
<lst name="defaults">
<str name="echoParams">explicit</str>
<str name="json.nl">map</str>
</lst>
<arr name="components">
<str>collapse</str>
<str>localsolr</str>
<str>facet</str>
</arr>
</requestHandler>
If you don't add the json.nl=map to your params, then you can't eval() what you get back in Ruby
("can't convert String into Integer"). Not sure if this can be put into the RubyResponseWriter as a
default. Also not sure if this an issue with the python writer either (since I don't use python).
Doug
Yonik Seeley wrote:
Thanks Doug, I just checked in your fix.
This was a recent bug... writing of SolrDocument was recently added
and is not touched by normal code paths, except for distributed
search.
-Yonik
On Wed, Mar 5, 2008 at 9:29 AM, Doug Steigerwald
<[EMAIL PROTECTED]> wrote:
We're using localsolr and the RubyResponseWriter. When we do a request with
the localsolr component
in our requestHandler we're seeing issues with the display of a multivalued
field when it only has
one value.
'class'=>['showtime']'showtime', <------
'genre'=>['Drama',
'Suspsense/Triller'],
With no localsolr component it works fine.
Looks like the issue is with the JSONRequestWriter.writeSolrDocument().
Here's the small patch for
it that seems to fix it.
Index: src/java/org/apache/solr/request/JSONResponseWriter.java
===================================================================
--- src/java/org/apache/solr/request/JSONResponseWriter.java (revision
614955)
+++ src/java/org/apache/solr/request/JSONResponseWriter.java (working copy)
@@ -416,7 +416,7 @@
writeVal(fname, val);
writeArrayCloser();
}
- writeVal(fname, val);
+ else writeVal(fname, val);
}
if (pseudoFields !=null && pseudoFields.size()>0) {
We're running solr trunk r614955 (Jan 23rd), and r75 of localsolr.
Result snippet with the patch:
'class'=>['showtime'],
'genre'=>['Drama',
'Suspsense/Triller'],
Has anyone come across an issue like this? Is this fixed in a newer build of
Solr? It looks like
we'd still need this patch even in a build of the solr trunk from yesterday,
but maybe not.
--
Doug Steigerwald
Software Developer
McClatchy Interactive
[EMAIL PROTECTED]
919.861.1287
