Re: more granular updateRequestProcessorChain

2011-10-05 Thread Mikhail Khludnev 
Jan,

Shame on me, I was off for some time. I have a catch-all field - initially
I copied n fields into the single one. But then I had to add a special
payload per copied fields, and I've done it by Analyzer.

for(src : srcFiledNames ){
   payload = new MyPayloadTokenStream(input.get(src));
   doc.add(new Field(destination,  payload));
}

How it can be done?

--
Mikhail Khludnev

On Wed, Aug 31, 2011 at 3:52 PM, Jan Høydahl jan@cominvent.com wrote:

 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
 mkhlud...@griddynamics.com





-- 
Sincerely yours
Mikhail (Mike) Khludnev
Developer
Grid Dynamics
tel. 1-415-738-8644
Skype: mkhludnev
 http://www.griddynamics.com
mkhlud...@griddynamics.com

Re: more granular updateRequestProcessorChain

2011-10-05 Thread Jan Høydahl 
Hi,

If you want to add payloads in the UpdateChain, have a look at 
DelimitedPayloadTokenFilter. Put that in your FieldType, and create a Processor 
which annotates the text with payloads, e.g.:

field name=textfoo|2.0 bar|3.0/field

Using DelimitedPayloadTokenFilter with delimiter=| you can now get the 
payload 2.0 indexed for foo and 3.0 for bar.

Perhaps you should have a look at DisMax request handler as well, which for 
many use cases is a better option than using catch-all field.

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

On 5. okt. 2011, at 21:49, Mikhail Khludnev wrote:

 Jan,
 
 Shame on me, I was off for some time. I have a catch-all field - initially 
 I copied n fields into the single one. But then I had to add a special 
 payload per copied fields, and I've done it by Analyzer.  
 
 for(src : srcFiledNames ){
payload = new MyPayloadTokenStream(input.get(src));
doc.add(new Field(destination,  payload));
 }
 
 How it can be done?
 
 --
 Mikhail Khludnev
 
 On Wed, Aug 31, 2011 at 3:52 PM, Jan Høydahl jan@cominvent.com wrote:
 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
 
 
 
 
 
 -- 
 Sincerely yours
 Mikhail (Mike) Khludnev
 Developer
 Grid Dynamics
 tel. 1-415-738-8644
 Skype: mkhludnev

Re: more granular updateRequestProcessorChain

2011-08-31 Thread Yonik Seeley 
On Wed, Aug 31, 2011 at 7:52 AM, Jan Høydahl jan@cominvent.com wrote:
 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?

Indeed - I've started going in the opposite direction and removed the
lucene Document from the AddUpdateCommand altogether (see SOLR-2700).

-Yonik
http://www.lucidimagination.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

more granular updateRequestProcessorChain

2011-08-17 Thread Mikhail Khludnev 
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
mkhlud...@griddynamics.com