Hi all,
I'm having an issue with using a custom fieldtype with distributed search. It may be the case that what I'm looking for could be accomplished in a different way, but this is my first stab at it.

I'm looking to store XML in a field. What I've done, which works fine, is to:
- on ingest, wrap the XML in a CDATA tag
- write a simple class that extends org.apache.solr.schema.TextField, which writes an XML node much in the way that a textfield would, but without escaping the contents

It looks like this:
public class XMLField extends TextField {
   @Override
public void write(TextResponseWriter xmlWriter, String name, Fieldable f)
         throws java.io.IOException {
      Writer writer = xmlWriter.getWriter();
      writer.write("<xml name=" + '"' + name + '"' + '>');
writer.write(f.stringValue(), 0, f.stringValue() == null ? 0 : f.stringValue().length());
      writer.write("</xml>");
 }
}

Like I said, simple. Not especially pretty, but it does the job. Works fine for normal searching, I get back a response like:
<xml name="xmlField"><xml-contents-unescaped/></xml>

When I try to use this with distributed searching, though, it comes back written as a normal textfield, like:
<str name="xmlField">&lt;xml-contents-have-been-escaped/&gt;</str>

It looks like it doesn't know anything about my custom fieldtype at all, and is defaulting to writing it as a StrField or TextField instead.

So, my question:
- is there a better way to do this? I'd be fine if it came back with a 'str' element name, as long as it's not escaped. - is there perhaps a different class I should extend to do this with sharded searching? - should I just bite the bullet and manually unescape the xml after receiving the response? I'd really prefer not to do this if I can get around it.

Thanks in advance for any help.

Peter

Reply via email to