lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Baranczak <MBaranc...@ePublishing.com>
Subject Re: [jira] Commented: (SOLR-16) patch to allow the use of a custom query output writer
Date Sat, 27 May 2006 05:11:46 GMT

On May 26, 2006, at 9:52 PM, Erik Hatcher wrote:

>
> On May 26, 2006, at 4:07 PM, Mike Baranczak wrote:
>
>> On May 26, 2006, at 3:15 PM, Yonik Seeley wrote:
>>
>>>> Mike - thank you for your patience in refactoring what was  
>>>> already working for
>>>> you into something more generalizable than you needed for the  
>>>> benefit of the >community.  I personally will be experimenting  
>>>> with this new feature.
>>>
>>> Seconded!  Thanks Mike!
>>> Can you share how you are using pluggable response writers?
>>>
>>> -Yonik
>>
>>
>> Basically, I wanted the ability to do some custom processing of  
>> the document fields before displaying them to the user. I thought  
>> it made sense to do it right in the search server, to avoid  
>> sending unnecessary data across the network; but I couldn't figure  
>> out a good way to do it within the existing architecture, so I  
>> made an XML output module that completely bypasses XMLWriter.
>>
>> I thought about contributing some of this code as well, but it  
>> probably won't happen, since it contains a lot of stuff that only  
>> makes sense for our own system.
>
> It seems the real need you had was to replace pieces of the  
> XMLWriter output "pipeline" with custom data.  I wanted to add  
> highlighting in at the deep level but it would need to be sort of  
> hard-coded in there.  We need a way to have streaming output  
> plugins, perhaps ala HiveMind which I'd like to eventually tinker  
> with as a way to configure Solr.  In my copious free time, of course.

The problem with XMLWriter is that it combines two functions that  
should really be separate: retrieving the data from the index, and  
rendering that data as XML. This intertwining makes it impossible to  
manipulate the data in between those two stages. My first plan of  
attack was to try either subclassing or patching XMLWriter so that it  
allows some sort of "filter" plug-in, but for my immediate needs I  
thought it better to just bypass it.

Highlighting definitely shouldn't be done in a low-level, hard-coded  
fashion, because everyone has a different idea of what highlighting  
should look like. I don't know anything about HiveMind, but I agree  
that a more modular, pluggable output architecture would be good.  
This patch is a step in that direction, and it works for what I'm  
doing, but it doesn't provide fine-grained control - you're either  
using XMLWriter or you have to re-implement the whole output module  
yourself.

-MB



Mime
View raw message