lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <jan....@cominvent.com>
Subject Re: more granular updateRequestProcessorChain
Date Wed, 31 Aug 2011 11:52:53 GMT
Hi,

Can you explain the wanted functional result of your copy operation? I've done copying fields
in processors without trouble.
What do you want to do with the Lucene Document?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com

On 17. aug. 2011, at 09.51, Mikhail Khludnev wrote:

> Hello,
> 
> I need to implement some tricky copyField like in http://wiki.apache.org/solr/UpdateRequestProcessor.

> But I need to take the SolrInputDocument field and put it into Lucene document myself
by my own UpdateRequestProcessor. Unfortunately there is no room to do that because the creating
Lucene document and its' indexing it is the single method: 
> 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(AddUpdateCommand)
>  {
>     cmd.doc = DocumentBuilder.toDocument(cmd.getSolrInputDocument(), req.getSchema());
>     updateHandler.addDoc(cmd);
>     super.processAdd(cmd);
>   }
> 
> I was surprised because the Chain-of-responsibility and Command pattern are made for
such usages.
> 
> I propose to separate the current RunUpdateProcessor onto BuildLuceneDocumentProcessor
and UpdateHandlerProcessor that allow users to inject their own routines in the main flow.

> Right now I had to copy-paste RunUpdateProcessor to get my purpose.
> 
> WDYT?
> 
> -- 
> Sincerely yours
> Mikhail (Mike) Khludnev
> Developer
> Grid Dynamics
> Skype: mkhludnev
> 


Mime
View raw message